You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by ch...@apache.org on 2013/11/11 18:27:56 UTC

svn commit: r1540788 [3/3] - /db/derby/docs/branches/10.10/src/adminguide/

Modified: db/derby/docs/branches/10.10/src/adminguide/cadminreplicstartrun.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.10/src/adminguide/cadminreplicstartrun.dita?rev=1540788&r1=1540787&r2=1540788&view=diff
==============================================================================
--- db/derby/docs/branches/10.10/src/adminguide/cadminreplicstartrun.dita (original)
+++ db/derby/docs/branches/10.10/src/adminguide/cadminreplicstartrun.dita Mon Nov 11 17:27:54 2013
@@ -20,59 +20,55 @@ limitations under the License.
 -->
 <concept id="cadminreplicstartrun" xml:lang="en-us">
 <title>Starting and running replication</title>
+<shortdesc>Each replicated database is replicated from a master to a slave
+version of that database.</shortdesc>
 <prolog><metadata><keywords>
 <indexterm>replicating databases<indexterm>starting and running</indexterm></indexterm>
 <indexterm>database replication<indexterm>starting and running</indexterm></indexterm>
 </keywords></metadata></prolog>
 <conbody>
-<p>Each replicated database is replicated from a master to a slave version of
-that database. Initially there is no replication; a master database must be
-created before it can be replicated. The database may, of course, be empty when
-replication starts. On the other hand, replication does not need to be specified
-immediately after the database is created; it can be initiated at any time after
-the database is created.
-</p>
+<p>Initially there is no replication; a master database must be created before
+it can be replicated. The database may, of course, be empty when replication
+starts. On the other hand, replication does not need to be specified immediately
+after the database is created; it can be initiated at any time after the
+database is created.</p>
 <p>Before you start replication, you must shut down the master database and then
 copy the database to the slave location. Follow these
-steps to start replication:
-</p>
+steps to start replication:</p>
 <ol>
 <li>Make sure that the database on the master system is shut down cleanly.</li>
 <li>Copy the database to the slave location.</li>
-<li>Start slave replication mode on the Derby instance that is acting
+<li>Start slave replication mode on the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> instance that is acting
 as the slave for the database. To start slave replication, use the
-<i>startSlave=true</i> attribute and, optionally, the <i>slaveHost=hostname</i>
-and <i>slavePort=portValue</i> attributes. For example, for a database named
-<codeph>wombat</codeph>, you might use the following connection URL:
-<codeblock>
-jdbc:derby:wombat;startSlave=true
-</codeblock></li>
-<li>Start master replication mode on the Derby instance that is acting as the
-master for the database. To start replication, connect to the database on the
-master system using the <i>startMaster=true</i> attribute in conjunction with
-the <i>slaveHost=hostname</i> attribute (and, optionally, the
-<i>slavePort=portValue</i> attribute). For example, you might use the following
-connection URL:
-<codeblock>
-jdbc:derby:wombat;startMaster=true;slaveHost=myremotesystem
-</codeblock>
-A successful use of the <i>startMaster=true</i> attribute will also start the
-database.
-</li>
+<codeph>startSlave=true</codeph> attribute and, optionally, the
+<codeph>slaveHost=<i>hostname</i></codeph> and
+<codeph>slavePort=<i>portValue</i></codeph> attributes. For example, for a
+database named <codeph>wombat</codeph>, you might use the following connection
+URL:
+<codeblock>jdbc:derby:wombat;startSlave=true</codeblock></li>
+<li>Start master replication mode on the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> instance that is acting
+as the master for the database. To start replication, connect to the database on
+the master system using the <codeph>startMaster=true</codeph> attribute in
+conjunction with the <codeph>slaveHost=<i>hostname</i></codeph> attribute (and,
+optionally, the <codeph>slavePort=<i>portValue</i></codeph> attribute). For
+example, you might use the following connection URL:
+<codeblock>jdbc:derby:wombat;startMaster=true;slaveHost=myremotesystem</codeblock>
+A successful use of the <codeph>startMaster=true</codeph> attribute will also
+start the database.</li>
 </ol>
 <p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for details about these
 attributes.</p>
-<p>After replication has been started, the slave
-is ready to receive logged operations from the master. The master can now
-continue to process transactions. From this point on, the master forwards all
-logged operations to the slave in chunks. The slave repeats
-these operations by applying the contents of the <ph
-conref="../conrefs.dita#prod/productshortname"></ph> transaction log, but does
-not process any other operations. Attempts to connect to the slave database are
-refused. In case of failure, the slave can recover to the state the master was
-in at the time the last chunk of the transaction log was sent.
-</p>
-<p> While replication is running, neither the slave or the master database is
+<p>After replication has been started, the slave is ready to receive logged
+operations from the master. The master can now continue to process transactions.
+From this point on, the master forwards all logged operations to the slave in
+chunks. The slave repeats these operations by applying the contents of the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> transaction log, but
+does not process any other operations. Attempts to connect to the slave database
+are refused. In case of failure, the slave can recover to the state the master
+was in at the time the last chunk of the transaction log was sent.</p>
+<p>While replication is running, neither the slave or the master database is
 permitted to be shut down. Replication must be stopped before you can shut down
 either the slave or the master database. There is one exception to this rule:
 if the entire system is shut down, the peer that is shut down notifies the other

Modified: db/derby/docs/branches/10.10/src/adminguide/cadminreplicstop.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.10/src/adminguide/cadminreplicstop.dita?rev=1540788&r1=1540787&r2=1540788&view=diff
==============================================================================
--- db/derby/docs/branches/10.10/src/adminguide/cadminreplicstop.dita (original)
+++ db/derby/docs/branches/10.10/src/adminguide/cadminreplicstop.dita Mon Nov 11 17:27:54 2013
@@ -20,28 +20,25 @@ limitations under the License.
 -->
 <concept id="cadminreplicstop" xml:lang="en-us">
 <title>Stopping replication</title>
+<shortdesc>To stop replication of a database, connect to the master database
+using the <codeph>stopMaster=true</codeph> connection URL attribute.</shortdesc>
 <prolog><metadata><keywords>
 <indexterm>replicating databases<indexterm>stopping</indexterm></indexterm>
 <indexterm>database replication<indexterm>stopping</indexterm></indexterm>
 </keywords></metadata></prolog>
 <conbody>
-<p>To stop replication of a database, connect to the master database using the
-<i>stopMaster=true</i> connection URL attribute. The master sends the remaining
-log records that await shipment, and then sends a stop replication command to
-the slave. The slave then writes all logs to disk and shuts down the database.
-For example, for a database named <codeph>wombat</codeph>, you might specify the
-following connection URL:</p>
-<codeblock>
-jdbc:derby:wombat;stopMaster=true
-</codeblock>
+<p>The master sends the remaining log records that await shipment, and then
+sends a stop replication command to the slave. The slave then writes all logs to
+disk and shuts down the database. For example, for a database named
+<codeph>wombat</codeph>, you might specify the following connection URL:</p>
+<codeblock>jdbc:derby:wombat;stopMaster=true</codeblock>
 <p>To stop replication on the slave system if the connection to the master is
-lost, use the <i>stopSlave=true</i> connection URL attribute.
-</p>
+lost, use the <codeph>stopSlave=true</codeph> connection URL attribute.</p>
 <p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for details about these
 attributes.</p>
 <p>You cannot resume replication after it has been stopped. You need to start
-replication over again from the beginning using the <i>startMaster=true</i>
-attribute, as described in
-<xref href="cadminreplicstartrun.dita#cadminreplicstartrun"></xref>.
-</p></conbody>
+replication over again from the beginning using the
+<codeph>startMaster=true</codeph> attribute, as described in
+<xref href="cadminreplicstartrun.dita#cadminreplicstartrun"></xref>.</p>
+</conbody>
 </concept>

Modified: db/derby/docs/branches/10.10/src/adminguide/cadminrollforward.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.10/src/adminguide/cadminrollforward.dita?rev=1540788&r1=1540787&r2=1540788&view=diff
==============================================================================
--- db/derby/docs/branches/10.10/src/adminguide/cadminrollforward.dita (original)
+++ db/derby/docs/branches/10.10/src/adminguide/cadminrollforward.dita Mon Nov 11 17:27:54 2013
@@ -33,11 +33,11 @@ recovery</indexterm></indexterm></keywor
 <p><ph conref="../conrefs.dita#prod/productshortname"></ph> restores a database
 from full backup and replays all the transactions after the backup. All the
 log files after a backup are required to replay the transactions after the
-backup. By default, the database keeps only logs that are required for crash-recovery.
-For roll-forward recovery to be successful, all log files must be archived
-after a backup. Log files can be archived using the backup function calls
-that enable log archiving.</p>
-<p>In roll-forward recovery the log archival mode ensures that all old log
+backup. By default, the database keeps only logs that are required for
+crash recovery. For roll-forward recovery to be successful, all log files must
+be archived after a backup. Log files can be archived using the backup function
+calls that enable log archiving.</p>
+<p>In roll-forward recovery, the log archival mode ensures that all old log
 files are available. The log files are available only from the time that the
 log archival mode is enabled. </p>
 <p><ph conref="../conrefs.dita#prod/productshortname"></ph> uses the following
@@ -46,14 +46,15 @@ information to restore the database: <ul
 <li>The set of archived logs</li>
 <li>The current online active log</li>
 </ul></p>
-<p>You cannot use roll-forward recovery to restore individual tables. Roll-forward
-recovery recovers the entire database.</p>
-<p>To restore a database by using roll-forward recovery, you must already
-have a backup copy of the database, all the archived logs since the backup
-was created, and the active log files. All the log files should be in the
-database log directory.</p>
-<p>There are two types of log files in <ph conref="../conrefs.dita#prod/productshortname"></ph>:
-active logs and online archived logs.</p>
+<p>You cannot use roll-forward recovery to restore individual tables.
+Roll-forward recovery recovers the entire database.</p>
+<p>To restore a database by using roll-forward recovery, you must already have a
+backup copy of the database, all the archived logs since the backup was created,
+and the active log files. All the log files should be in the database log
+directory.</p>
+<p>There are two types of log files in
+<ph conref="../conrefs.dita#prod/productshortname"></ph>: active logs and online
+archived logs.</p>
 <dl><dlentry>
 <dt>Active logs</dt>
 <dd>Active logs are used during crash recovery to prevent a failure that might
@@ -62,55 +63,62 @@ use the active logs to recover to the en
 located in the database log path directory.</dd>
 </dlentry><dlentry>
 <dt>Online archived logs</dt>
-<dd>Log files that are stored for roll-forward recovery use when they are
-no longer needed for crash recovery. Online archived logs are also kept in
-the database log path directory.</dd>
+<dd>Log files that are stored for roll-forward recovery use when they are no
+longer needed for crash recovery. Online archived logs are also kept in the
+database log path directory.</dd>
 </dlentry></dl>
-<p><b>Enabling log archival mode</b></p>
+<section><title>Enabling log archival mode</title>
 <p>Online archive logs are available only if the database is enabled for log
 archival mode. You can use the following system procedure to enable the database
 for log archival mode:</p>
 <codeblock>SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE
 (IN BACKUPDIR VARCHAR(32672), IN SMALLINT DELETE_ARCHIVED_LOG_FILES)</codeblock>
-<p>The input parameters for the calls in the previous example specify the
-location where the backup should be stored and specify whether or not the
-database should keep online archived logs for the backup. Existing online
-archived log files that were created before this backup will be deleted if
-the input parameter value for the <i>DELETE_ARCHIVED_LOG_FILES</i> parameter
-is non-zero. The log files are deleted only after a successful backup. <note>Make
-sure to store the backup database in a safe place when you choose the log
-file removal option.</note></p>
-<p>The SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE procedure
-will issue an error if there are any unlogged operations in the same transaction
-as backup procedure.</p>
+<p>The input parameters for this procedure specify the location where the backup
+should be stored and specify whether or not the database should keep online
+archived logs for the backup. Existing online archived log files that were
+created before this backup will be deleted if the input parameter value for the
+<codeph>DELETE_ARCHIVED_LOG_FILES</codeph> parameter is non-zero. The log files
+are deleted only after a successful backup.
+<note>Make sure to store the backup database in a safe place when you choose the
+log file removal option.</note></p>
+<p>The
+<codeph>SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE</codeph>
+procedure will issue an error if there are any unlogged operations in the same
+transaction as the backup procedure.</p>
 <p>If any unlogged operations are in progress in other transactions in the
-system when the backup starts, this procedure will block until those transactions
-are complete before performing the backup. Derby automatically converts unlogged
-operations to logged mode if they are started while the backup is in progress
-(except operations that maintain application jar files in the database). Procedures
-to install, replace, and remove jar files in a database are blocked while
-the backup is in progress.</p>
-<p>If you do not want backup to block until unlogged operations in other transactions
-are complete, use the SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT
-procedure. This procedure issues an error immediately at the start of the
-backup if there are any transactions in progress with unlogged operations,
-instead of waiting for those transactions to complete.</p>
-<p><b>Disabling log archival mode</b></p>
+system when the backup starts, this procedure will block until those
+transactions are complete before performing the backup.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> automatically converts
+unlogged operations to logged mode if they are started while the backup is in
+progress (except operations that maintain application jar files in the
+database). Procedures to install, replace, and remove jar files in a database
+are blocked while the backup is in progress.</p>
+<p>If you do not want backup to block until unlogged operations in other
+transactions are complete, use the
+<codeph>SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT</codeph>
+procedure. This procedure issues an error immediately at the start of the backup
+if there are any transactions in progress with unlogged operations, instead of
+waiting for those transactions to complete.</p>
+</section>
+<section><title>Disabling log archival mode</title>
 <p>After you enable log archival mode, the database will always have the log
 archival mode enabled even if it is subsequently booted or backed up. The
 only way to disable the log archive mode is to run the following procedure:</p>
-<codeblock>SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(IN SMALLINT DELETE_ARCHIVED_LOG_FILES)</codeblock>
+<codeblock>SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE
+(IN SMALLINT DELETE_ARCHIVED_LOG_FILES)</codeblock>
 <p>This system procedure disables the log archive mode and deletes any existing
-online archived log files if the input parameter <i>DELETE_ARCHIVED_LOG_FILES</i> is
-non-zero.</p>
-<p><b>Performing roll-forward recovery</b></p>
+online archived log files if the input parameter
+<codeph>DELETE_ARCHIVED_LOG_FILES</codeph> is non-zero.</p>
+</section>
+<section><title>Performing roll-forward recovery</title>
 <p>If you have a backup made by using
-SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE or
-SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT, you can
-restore it to its most recent state by using the full backup copy, archived
-logs, and active logs. You perform a roll-forward recovery by specifying the
-connection URL attribute <i>rollForwardRecoveryFrom=path</i> at boot time. All
-the log files should be in the database log path directory.</p>
+<codeph>SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE</codeph> or
+<codeph>SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT</codeph>,
+you can restore it to its most recent state by using the full backup copy,
+archived logs, and active logs. You perform a roll-forward recovery by
+specifying the connection URL attribute
+<codeph>rollForwardRecoveryFrom=<i>path</i></codeph> at boot time. All the log
+files should be in the database log path directory.</p>
 <p>The steps involved are as follows. They do not show the commands to start
 <codeph>ij</codeph>.</p>
 <ol>
@@ -141,10 +149,10 @@ cd /databases</b></codeblock>
 </li>
 <li><b>Restore the database using roll-forward recovery.</b>
 <p>Since you moved the database, you need to specify the
-<i>logDevice=logDirectoryPath</i> attribute in addition to the
-<i>rollForwardRecoveryFrom=path</i> attribute when you restore the database
-using roll-forward recovery. Use commands like the following (the connection URL
-must be all on one line):</p>
+<codeph>logDevice=<i>logDirectoryPath</i></codeph> attribute in addition to the
+<codeph>rollForwardRecoveryFrom=<i>path</i></codeph> attribute when you restore
+the database using roll-forward recovery. Use commands like the following (the
+connection URL must be all on one line):</p>
 <codeblock>ij> <b>connect 'jdbc:derby:wombat;rollForwardRecoveryFrom=/backup/wombat;
 logDevice=/databases/brokenwombat';</b>
 ij> <b>select * from t1;</b>
@@ -157,11 +165,12 @@ A          
 <p>After a database is restored from full backup, transactions from the online
 archived logs and active logs are replayed. This brings the database to its most
 recent state. All the log files should be in the directory specified by the
-<i>logDevice=logDirectoryPath</i> attribute.</p>
+<codeph>logDevice=<i>logDirectoryPath</i></codeph> attribute.</p>
 </li>
 </ol>
 <p>For more information, see "rollForwardRecoveryFrom=path attribute" and
 "logDevice=logDirectoryPath attribute" in the
 <ph conref="../conrefs.dita#pub/citref"></ph>.</p>
+</section>
 </conbody>
 </concept>

Modified: db/derby/docs/branches/10.10/src/adminguide/cadminservlet98430.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.10/src/adminguide/cadminservlet98430.dita?rev=1540788&r1=1540787&r2=1540788&view=diff
==============================================================================
--- db/derby/docs/branches/10.10/src/adminguide/cadminservlet98430.dita (original)
+++ db/derby/docs/branches/10.10/src/adminguide/cadminservlet98430.dita Mon Nov 11 17:27:54 2013
@@ -18,21 +18,25 @@ See the License for the specific languag
 limitations under the License.
 -->
 <concept id="cadminservlet98430" xml:lang="en-us">
-<title>Managing the Derby Network Server remotely by using the servlet interface</title>
+<title>Managing the <ph conref="../conrefs.dita#prod/productshortname"></ph>
+Network Server remotely by using the servlet interface</title>
 <shortdesc>You can use the servlet interface to manage the Network Server
 remotely. To use the servlet interface, the servlet must be registered with
-an Application Server, and derby.system.home must be known to the Application Server.</shortdesc>
+an Application Server, and <codeph>derby.system.home</codeph> must be known to
+the Application Server.</shortdesc>
 <conbody>
 <p><note type="important">The servlet interface is suitable only for testing
 purposes. It should not be used in production.</note></p>
-<p>A Web application archive (WAR) file, <i>derby.war</i>, for the <ph conref="../conrefs.dita#prod/productshortname"></ph> 
-Network Server is available in <i>$<ph conref="../conrefs.dita#prod/productinstallpath"></ph>/lib.</i> This
-file registers the Network Server's servlet at the relative path <i>/derbynet</i>.
-See the documentation for your Application Server for instructions on how
-to install it.</p>
-<p>For example, if <i>derby.war</i> is installed in WebSphere Application
-Server with a context root of <filepath>derby</filepath>, the URL of the server
-is:</p>
+<p>A web application archive (WAR) file for the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> Network Server,
+<codeph>derby.war</codeph>, is available in
+<codeph>$<ph conref="../conrefs.dita#prod/productinstallpath"></ph>/lib</codeph>.
+This file registers the Network Server's servlet at the relative path
+<codeph>/derbynet</codeph>. See the documentation for your Application Server
+for instructions on how to install it.</p>
+<p>For example, if <codeph>derby.war</codeph> is installed in WebSphere
+Application Server with a context root of <codeph>derby</codeph>, the URL of the
+server is:</p>
 <codeblock>http://&lt;server>[:port]/derby/derbynet</codeblock>
 <note othertype="Notes" type="other">
 <ul><li>A servlet engine is not part of the Network Server.</li>
@@ -54,19 +58,18 @@ initialized.</dd>
 </dlentry><dlentry>
 <dt>tracingDirectory</dt>
 <dd>Specifies the location for trace files. If the tracing directory is not
-specified, the traces are placed in <i>derby.system.home</i>.</dd>
+specified, the traces are placed in <codeph>derby.system.home</codeph>.</dd>
 </dlentry></dl>
-<section><title>Security Considerations</title><p>
-For general security considerations for the Network Server, see
-<xref href="cadminnetservsecurity.dita"></xref>.</p><p>
-The "host" parameter allows configuration of the host name that will
-be used for the listening socket for network connections. By default,
-the Network Server will listen to requests only on the loopback
-address, which means that it will only accept connections from the
-local host. Changing this value could expose the server to
-external connections, which raises security concerns, so before using
-the "host" parameter, you should run under the Java security
-manager and enable user authentication.</p>
+<section><title>Security Considerations</title>
+<p>For general security considerations for the Network Server, see
+<xref href="cadminnetservsecurity.dita"></xref>.</p>
+<p>The <codeph>host</codeph> parameter allows configuration of the host name
+that will be used for the listening socket for network connections. By default,
+the Network Server will listen to requests only on the loopback address, which
+means that it will only accept connections from the local host. Changing this
+value could expose the server to external connections, which raises security
+concerns, so before using the <codeph>host</codeph> parameter, you should run
+under the Java security manager and enable user authentication.</p>
 <p>This section describes the servlet pages.</p>
 </section>
 </conbody>

Modified: db/derby/docs/branches/10.10/src/adminguide/cadminspace21579.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.10/src/adminguide/cadminspace21579.dita?rev=1540788&r1=1540787&r2=1540788&view=diff
==============================================================================
--- db/derby/docs/branches/10.10/src/adminguide/cadminspace21579.dita (original)
+++ db/derby/docs/branches/10.10/src/adminguide/cadminspace21579.dita Mon Nov 11 17:27:54 2013
@@ -20,54 +20,62 @@ limitations under the License.
 -->
 <concept id="cadminspace21579" xml:lang="en-us">
 <title>Reclaiming unused space</title>
-<shortdesc>A <ph conref="../conrefs.dita#prod/productshortname"></ph> table
-or index (sometimes called a <i>conglomerate</i>) can contain unused space
-after large amounts of data have been deleted or updated.</shortdesc>
+<shortdesc>A <ph conref="../conrefs.dita#prod/productshortname"></ph> table or
+index (sometimes called a <i>conglomerate</i>) can contain unused space after
+large amounts of data have been deleted or updated.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>Compressing tables and indexes</indexterm><indexterm>conglomerate<indexterm>description</indexterm></indexterm>
+<keywords><indexterm>Compressing tables and indexes</indexterm>
+<indexterm>conglomerate<indexterm>description</indexterm></indexterm>
 </keywords>
 </metadata></prolog>
 <conbody>
-<p>This happens because, by default, <ph conref="../conrefs.dita#prod/productshortname"></ph> does
-not return unused space to the operating system. After a page has been allocated
-to a table or index, <ph conref="../conrefs.dita#prod/productshortname"></ph> does
-not automatically return the page to the operating system until the table
-or index is dropped, even if the space is no longer needed. However, <ph conref="../conrefs.dita#prod/productshortname"></ph> does
-provide a way to reclaim unused space in tables and associated indexes.</p>
+<p>This happens because, by default,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> does not return unused
+space to the operating system. After a page has been allocated to a table or
+index, <ph conref="../conrefs.dita#prod/productshortname"></ph> does not
+automatically return the page to the operating system until the table or index
+is dropped, even if the space is no longer needed. However,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> does provide a way to
+reclaim unused space in tables and associated indexes.</p>
 <p>If you determine that a table and its indexes have a significant amount
-of unused space, use either the SYSCS_UTIL.SYSCS_COMPRESS_TABLE or SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE
-procedure to reclaim that space. SYSCS_COMPRESS_TABLE is guaranteed to recover
-the maximum amount of free space, at the cost of temporarily creating new
-tables and indexes before the statement is committed. SYSCS_INPLACE_COMPRESS
-attempts to reclaim space within the same table, but cannot guarantee it will
-recover all available space. The difference between the two procedures is
-that unlike SYSCS_COMPRESS_TABLE, the SYSCS_INPLACE_COMPRESS procedure uses
-no temporary files and moves rows around within the same conglomerate.</p>
+of unused space, use either the <codeph>SYSCS_UTIL.SYSCS_COMPRESS_TABLE</codeph>
+or <codeph>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE</codeph> procedure to reclaim
+that space. <codeph>SYSCS_UTIL.SYSCS_COMPRESS_TABLE</codeph> is guaranteed to
+recover the maximum amount of free space, at the cost of temporarily creating
+new tables and indexes before the statement is committed.
+<codeph>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE</codeph> attempts to reclaim
+space within the same table, but cannot guarantee it will recover all available
+space. The difference between the two procedures is that unlike
+<codeph>SYSCS_UTIL.SYSCS_COMPRESS_TABLE</codeph>, the
+<codeph>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE</codeph> procedure uses no
+temporary files and moves rows around within the same conglomerate.</p>
 <p>
-You can use the SYSCS_DIAG.SPACE_TABLE diagnostic table to estimate the
-amount of unused space in a table or index by examining, in particular, the
-values of the NUMFREEPAGES and ESTIMSPACESAVING columns. For example:
-</p>
-<codeblock>
-SELECT * FROM TABLE(SYSCS_DIAG.SPACE_TABLE('APP', 'FLIGHTAVAILABILITY')) AS T
-</codeblock>
-<p>
-For more information about SYSCS_DIAG.SPACE_TABLE, see "SYSCS_DIAG
-diagnostic tables and functions" in the
-<cite><ph conref="../conrefs.dita#pub/citref"></ph></cite>.
-</p>
-<example><p>As an example, after you have determined that the FlightAvailability
-table and its related indexes have too much unused space, you could reclaim
-that space with the following command:</p><codeblock>call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'FLIGHTAVAILABILITY', 0);</codeblock><p> The
-third parameter in the SYSCS_UTIL.SYSCS_COMPRESS_TABLE() procedure determines
+You can use the <codeph>SYSCS_DIAG.SPACE_TABLE</codeph> diagnostic table to
+estimate the amount of unused space in a table or index by examining, in
+particular, the values of the NUMFREEPAGES and ESTIMSPACESAVING columns. For
+example:</p>
+<codeblock><b>SELECT * FROM TABLE(SYSCS_DIAG.SPACE_TABLE('APP', 'FLIGHTAVAILABILITY')) AS T</b></codeblock>
+<p>For more information about
+<codeph>SYSCS_DIAG.SPACE_TABLE</codeph> see "SYSCS_DIAG diagnostic tables and
+functions" in the <ph conref="../conrefs.dita#pub/citref"></ph>.</p>
+<example>
+<p>As an example, after you have determined that the
+<codeph>FlightAvailability</codeph> table and its related indexes have too much
+unused space, you could reclaim that space with the following command:</p>
+<codeblock><b>call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'FLIGHTAVAILABILITY', 0);</b></codeblock>
+<p>The third parameter in the
+<codeph>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE</codeph> procedure determines
 whether the operation will run in sequential or non-sequential mode. If you
-specify <codeph>0</codeph> for the third argument in the procedure, the operation
-will run in non-sequential mode. In sequential mode,<ph conref="../conrefs.dita#prod/productshortname"></ph> compresses
-the table and indexes sequentially, one at a time. Sequential compression
-uses less memory and disk space but is slower. To force the operation to run
-in sequential mode, substitute a non-zero SMALLINT value for the third argument.
-The following example shows how to force the procedure to run in sequential
-mode:</p><codeblock>call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'FLIGHTAVAILABILITY', 1);</codeblock></example>
-<section>For more information about this command, see the <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite>.</section>
+specify <codeph>0</codeph> for the third argument in the procedure, the
+operation will run in non-sequential mode. In sequential mode,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> compresses the table
+and indexes sequentially, one at a time. Sequential compression uses less memory
+and disk space but is slower. To force the operation to run in sequential mode,
+substitute a non-zero SMALLINT value for the third argument. The following
+example shows how to force the procedure to run in sequential mode:</p>
+<codeblock><b>call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'FLIGHTAVAILABILITY', 1);</b></codeblock>
+</example>
+<section>For more information about this command, see the
+<ph conref="../conrefs.dita#pub/citref"></ph>.</section>
 </conbody>
 </concept>

Modified: db/derby/docs/branches/10.10/src/adminguide/cadminssl.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.10/src/adminguide/cadminssl.dita?rev=1540788&r1=1540787&r2=1540788&view=diff
==============================================================================
--- db/derby/docs/branches/10.10/src/adminguide/cadminssl.dita (original)
+++ db/derby/docs/branches/10.10/src/adminguide/cadminssl.dita Mon Nov 11 17:27:54 2013
@@ -19,54 +19,49 @@ limitations under the License.
 -->
 <concept id="cadminssl" xml:lang="en-us">
 <title>Network encryption and authentication with SSL/TLS</title>
+<shortdesc>By default, all
+<ph conref="../conrefs.dita#prod/productshortname"></ph> network traffic is
+unencrypted, with the exception of user names and user passwords, which may be
+encrypted separately.</shortdesc>
 <prolog><metadata>
 <keywords><indexterm>Network Server<indexterm>SSL</indexterm></indexterm><indexterm>Network Server<indexterm>TLS</indexterm></indexterm><indexterm>SSL</indexterm><indexterm>TLS</indexterm></keywords>
 </metadata></prolog>
 <conbody>
-<p>By default, all <ph
-conref="../conrefs.dita#prod/productshortname"></ph> network traffic
-is unencrypted, with the exception of user names and user passwords
-which may be encrypted separately (See <xref
-href="cadminappsclientsecurity.dita#cadminappsclientsecurity"></xref>). There
-is also no network layer access control mechanism. For deployment
-scenarios where these are possible security issues, <ph
-conref="../conrefs.dita#prod/productshortname"></ph> Network Server
-supports network security with Secure Socket Layer/Transport Layer
-Security (SSL/TLS).
-</p>
-<p>With SSL/TLS, the client/server communication protocol is encrypted
-and both the client and the server may independently of each other
-require certificate based authentication of the other part.
-</p><p> It is assumed that the reader is somewhat familiar with SSL,
-key pairs and certificates. This documentation is also based on the
-Java Development Kit (JDK) and its <codeph>keytool</codeph> application.
-</p><p> For the remainder of this section, the term <i>SSL</i> is used
-for SSL/TLS and the term <i>peer</i> is used for the other part of the
-communication (The server's <i>peer</i> is the client and vice versa).
-</p>
-<p>SSL for <ph conref="../conrefs.dita#prod/productshortname"></ph>
-(both for client and for server) operates in three possible modes:
+<p>See <xref
+href="cadminappsclientsecurity.dita#cadminappsclientsecurity"></xref> for more
+information.</p>
+<p>There is also no network layer access control mechanism. For deployment
+scenarios where these are possible security issues, the <ph
+conref="../conrefs.dita#prod/productshortname"></ph> Network Server supports
+network security with Secure Socket Layer/Transport Layer Security
+(SSL/TLS).</p>
+<p>With SSL/TLS, the client/server communication protocol is encrypted, and
+both the client and the server may, independently of each other, require
+certificate-based authentication of the other part.</p>
+<p>It is assumed that the reader is somewhat familiar with SSL, key pairs, and
+certificates. This documentation is also based on the Java Development Kit (JDK)
+and its <codeph>keytool</codeph> application.</p>
+<p>For the remainder of this section, the term <i>SSL</i> is used for SSL/TLS,
+and the term <i>peer</i> is used for the other part of the communication (the
+server's <i>peer</i> is the client and vice versa).</p>
+<p>SSL for <ph conref="../conrefs.dita#prod/productshortname"></ph> (both for
+client and for server) operates in three possible modes:
 <dl>
 <dlentry><dt><b>off</b></dt><dd>The default, no SSL encryption</dd></dlentry>
 <dlentry><dt><b>basic</b></dt><dd>SSL encryption, no peer authentication</dd></dlentry>
 <dlentry><dt><b>peerAuthentication</b></dt><dd>SSL encryption and peer authentication</dd></dlentry>
 </dl>
 </p>
-<p>
-Peer authentication may be set either on the server or on the client
-or on both. Peer authentication means that the other side of the SSL
-connection is authenticated based on a trusted certificate installed
-locally. 
-</p>
-<p>Alternatively, a Certification Authority (CA) certificate may be
-installed locally and the peer has a certificate signed by that
-authority. How to achieve this is not descibed in this
-document. Consult your Java environment documentation for details on
-this.
-</p>
+<p>Peer authentication may be set on the server, on the client, or on both. Peer
+authentication means that the other side of the SSL connection is authenticated
+based on a trusted certificate installed locally.</p>
+<p>Alternatively, a Certification Authority (CA) certificate may be installed
+locally and the peer has a certificate signed by that authority. How to achieve
+this is not described in this document. Consult your Java environment
+documentation for details on this.</p>
 <p>
 <note type="attention">
-<i>If a plaintext client tries to communicate with an SSL server or an
+<i>If a plaintext client tries to communicate with an SSL server, or if an
 SSL client tries to communicate with a plaintext server, the plaintext
 side of the communication will see the SSL communication as noise and
 report protocol errors.</i>