Example 1
Use the CHANGE DATABASE statement to enable after-image
journaling:
CHANGE DATABASE PATHNAME 'PERSONNEL'
JOURNAL FILE IS 'DEPT3:PERSONNEL.AIJ'.
Example 2
You can also use CHANGE DATABASE to disable after-image
journaling:
RDO> CHANGE DATABASE FILENAME 'PERSONNEL'
cont> NOJOURNAL.
Example 3
The database shutdown feature is designed to ensure that active
users on a single node or across a cluster cannot access the
database while you perform administrative and maintenance
tasks. For instance, use this shutdown feature when you need
the database in a stable condition while performing backup and
restore options, or when you are tuning the database.
In the following example, a complete database shutdown is
performed for all users of a database residing on a common
disk in a cluster. The CHANGE DATABASE ... OPEN IS MANUAL
statement is used to prevent new users from automatically opening
that database when the first DML statement is executed on the
database.
$ RDO = "$RDO"
$ RDO CHANGE DATABASE FILENAME "$222$DUA17:[DBS]PERS" OPEN IS MANUAL.
$ REPLY/ALL "PERS.RDB database will be shut down in 15 minutes"
$ REPLY/ALL "Please complete any work with PERS before then"
$ WAIT 00:15:00.00
$ RMU/CLOSE/ABORT=FORCEX/CLUSTER $222$DUA17:[DBS]PERS
At this point, you are assured that no unprivileged users can
invoke this database. After opening the database with the
RMU/OPEN/ACCESS=RESTRICTED command (the /ACCESS=RESTRICTED
qualifier restricts database access to users with the DBADM
privilege), you can perform maintenance tasks like tuning without
interference from unprivileged users. For example, you can add
or delete indexes and compare the performance results in a stable
testing environment.
When you are ready to make the database available again across
the cluster, enter RDO and type:
RDO> CHANGE DATABASE FILE "$222$DUA17:[DBS]PERS"
cont> OPEN IS AUTOMATIC.
Example 4
The following example shuts down access to a clusterwide database
and then reopens the database for a specific node:
$ RDO = "$RDO"
$ RDO CHANGE DATABASE FILENAME "$222$DUA17:[DBS]PERS" OPEN IS MANUAL.
$ REPLY/ALL "PERS.RDB database will be shut down in 15 minutes"
$ REPLY/ALL "Please complete any work with PERS before then"
$ WAIT 00:15:00.00
$ RMU/CLOSE/ABORT=FORCEX/CLUSTER $222$DUA17:[DBS]PERS
$ !
$ SET HOST MADABT
.
.
.
$ ! On node MADABT now
$ RMU/OPEN $222$DUA17:[DBS]PERS
The RMU/OPEN command opens the PERS database on MADABT only.
Users logged into other nodes in the cluster who normally have
access to the clusterwide database cannot access it until:
o The RMU/OPEN command is executed by a user with sufficient
privilege on his or her node.
o Or, the CHANGE DATABASE ... OPEN IS AUTOMATIC statement is
executed by a user with sufficient privilege from any node in
the cluster.
Example 5
The following example shows how to disable snapshots on a
database:
RDO> CHANGE DATABASE FILENAME 'PERSONNEL' SNAPSHOT IS DISABLED.
Example 6
The following example uses the CHANGE DATABASE statement to
define a new storage area for a multifile database:
RDO> CHANGE DATABASE FILENAME 'MF_PERSONNEL'
cont> DEFINE STORAGE AREA ARCHIVED_EMPS
cont> FILENAME DISK3:ARCHIVED_EMPS
cont> ALLOCATION IS 50 PAGES
cont> PAGE FORMAT IS MIXED
cont> SNAPSHOT_FILENAME IS DISK4:ARCHIVED_EMPS
cont> END ARCHIVED_EMPS STORAGE AREA.
Example 7
This example uses the DICTIONARY IS REQUIRED option to enforce
use of the data dictionary if metadata updates occur. Users must
invoke the database with the PATHNAME argument to perform any
metadata changes.
Note that when you specify the DICTIONARY option, that is the
only option you can specify in a CHANGE DATABASE statement. To
specify other options, you must issue another CHANGE DATABASE
statement.
RDO> CHANGE DATABASE FILENAME 'PERSONNEL'
cont> DICTIONARY IS REQUIRED.
Example 8
This example uses the READ_ONLY clause to change the ARCHIVED_
EMPS storage area to a read-only storage area.
RDO> CHANGE DATABASE FILENAME 'MF_PERSONNEL'
cont> CHANGE STORAGE AREA ARCHIVED_EMPS
cont> READ_ONLY.
Example 9
This example uses the GLOBAL BUFFERS clause to enable global
buffers for the MF_PERSONNEL database.
RDO> CHANGE DATABASE FILENAME MF_PERSONNEL
cont> GLOBAL BUFFERS ARE ENABLED
cont> (NUMBER IS 50,
cont> USER LIMIT IS 10).
In this example, 50 is the number of global buffers and 10 is the
maximum number (user limit) of global buffers per user.
Example 10
This example enables fast commit processing with a transaction
interval of 10, and specifies checkpoint intervals of 512 blocks
and 12 seconds:
RDO> CHANGE DATABASE FILENAME TEST1
cont> JOURNAL FAST COMMIT ENABLED
cont> (CHECKPOINT INTERVAL IS 512 BLOCKS,
cont> CHECKPOINT TIMED EVERY 12 SECONDS,
cont> TRANSACTION INTERVAL IS 10).
Example 11
This example disables the carry-over lock optimization:
RDO> CHANGE DATABASE FILENAME TEST1
cont> CARRY OVER LOCKS ARE DISABLED.
Example 12
This example sets the default database lock timeout interval to
25 seconds. This is the database wide timeout interval. It is
used as the default as well as the upper limit in determining the
timeout interval to use. For example, if LOCK TIMEOUT INTERVAL
IS 25 SECONDS is specified with the CHANGE DATABASE or DEFINE
DATABASE statement, and a user specifies 30 seconds with the
SQL SET TRANSACTION WAIT 30 statement or sets the logical name
RDM$BIND_LOCK_TIMEOUT_INTERVAL to 30, RDO would still use the
interval of 25 specified with the LOCK TIMEOUT INTERVAL clause.
The maximum number of seconds that can be specified with the LOCK
TIMEOUT INTERVAL clause is 65,000:
RDO> CHANGE DATABASE FILENAME TEST1
cont> CARRY OVER LOCKS ARE ENABLED
cont> LOCK TIMEOUT INTERVAL IS 25 seconds.