Note that for page sizes of between 32 and 63 blocks the buffer size should be the same size as the page size.

Buffer Size	Page Sizes
1	1
2	1, 2
3	1, 3
4	1, 2, 4
5	1, 5
6	1, 2, 3, 6
7	1, 7
8	1, 2, 4, 8
9	1, 3, 9
10	1, 2, 5, 10
11	1, 11
12	1, 2, 3, 4, 6, 12
13	1, 13
14	1, 2, 7, 14
15	1, 3, 5, 15
16	1, 2, 4, 8, 16
17	1, 17
18	1, 2, 3, 6, 9, 18
19	1, 19
20	1, 2, 4, 5, 10, 20
21	1, 3, 7, 21
22	1, 2, 11, 22
23	1, 23
24	1, 2, 3, 4, 6, 8, 12, 24
25	1, 5, 25
26	1, 2, 13, 26
27	1, 3, 9, 27
28	1, 2, 4, 7, 14, 28
29	1, 29
30	1, 2, 3, 5, 6, 10, 15, 30
31	1, 31
32	1, 2, 4, 8, 16, 32
33	1, 3, 11, 33
34	1, 2, 17, 34
35	1, 5, 7, 35
36	1, 2, 3, 4, 6, 9, 12, 18, 36
37	1, 37
38	1, 2, 19, 38
39	1, 3, 13, 39
40	1, 2, 4, 5, 8, 10, 20, 40
41	1, 41
42	1, 2, 3, 6, 7, 14, 21, 42
43	1, 43
44	1, 2, 4, 11, 22, 44
45	1, 3, 5, 9, 15, 45
46	1, 2, 23, 46
47	1, 47
48	1, 2, 3, 4, 6, 8, 12, 16, 24, 48
49	1, 7, 49
50	1, 2, 5, 10, 25, 50
51	1, 3, 17, 51
52	1, 2, 4, 13, 26, 52
53	1, 53
54	1, 2, 3, 6, 9, 18, 27, 54
55	1, 5, 11, 55
56	1, 2, 4, 7, 8, 14, 28, 56
57	1, 3, 19, 57
58	1, 2, 29, 58
59	1, 59
60	1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60
61	1, 61
62	1, 2, 31, 62
63	1, 3, 7, 9, 21, 63

Specifies the RMU database backup file for a SysWorks Database Tools job.

By default, the RMU database backup file is created in or searched for in the application backup directory. The default file name is the file name of the database being backed up or restored with a suffix of an undescore followed by the 9's complemented date and time. This naming convention ensures that the newest backup file is found first in the backup directory. The default file type is .RBF.

Specifies the database root file for a SysWorks Database Tools job.

By default, the database root file is created in or searched for in the application RDB directory. The default file type is .RDB.

Note that where a database is copied, two database root files are required -- see RDB_FIL_SOURCE and RDB_FIL_TARGET for more details.

The source database root file specification controls which database the SysWorks Database Tools job copies from.

The target database root file specification controls which database the SysWorks Database Tools job copies to.

Specifies a list of tables which are to be loaded as part of a load action. This list may be a comma seperated list of table names or the specification of a file which contains the list of table names. If a file specification is supplied, it must be proceeded with an @ character. Lists of table names can be nested up to 10 levels deep.

Specifies whether to create and/or use snapshot files. A value of YES indicates that snapshot files should be created and their use enabled. A value of NO indicates that snapshot files should not be created and their use should be disabled.

Specifies whether to use the existing storage map and area definitions or generate new ones. A value of YES indicates that the existing model will be used. A value of NO (the default value) indicates that a new model is to be generated.

You may specify the maximum number of concurrent attachments (i.e. users) for the database. The value must be an integer between 1 and 10000.

You may select the verification level for your job.

The following responses are valid:

Code	Usage
DEBUG	Add DCL commands will be verified.
FULL	All job action commands will be verified.
MINIMUM	All significant job action commands will be verified.
NONE	There will be no verification of any commands.

Generally, job action commands include file maniplulation, RMU and SQL commands.

Analyze the areas and indices of the database using RMU/ANALYZE and LOAD the results of the analysis into the database.

Backup a database and its after image journals.

This task results in .AIB files created using the RMU/BACKUP/AFTER_JOURNAL command and a .RBF file created using the RMU/BACKUP.

Close the database using RMU/CLOSE. This step should be executed before any others.

Load all clues into the DBA tables.

Using the analysis data generated by the ANALYZE step, generate an SQL import script for the database.

Convert the database from one version of Rdb to another using RMU/CONVERT.

Copies a database or database backup from one context or sub-context to another.

Create an empty database. A script with a name of the form appl_DATABASE.SQL must exist for this task to proceed. The ANALYZE task produces such a script.

Drop an existing database using SQL DROP DATABASE. If the drop fails, a DCL DELETE is used to forcably delete the database files.

Ask for every possible parameter and display the parameter values. This task is used to test the SysWorks Database Tools.

Estimate average number of bytes added to the database for an insert of each row (excluding any trigger actions).

Export the database to an RBR file using SQL EXPORT.

Extract a schema from a database and convert it to a standard form. There are several ways of extracting the initial information. These include:

• Program which reads the database meta-data.
• RMU/EXTRACT command
• SQL SHOW statements.

When this task is selected, the extraction method parameter is needed. See HELP DBAMNU PARAMETERS EXT_MTH for more details.

The extraction process involves a number of intermediate steps which result in a number of SQL scripts and/or listings. The final results are derived from these intermediate files and should be the same for both extraction methods.

Generate a schema from a database extraction.

Import the database from an RBR file using SQL IMPORT and any script created by the CONFIGURE step.

Recreate the after image journals for a database. This is automatically performed as one of the last steps for a COPY, CREATE, IMPORT, RECOVER or RESTORE task. Explicit inclusion of this task should normally only be considered after a full database backup.

Load data into one or more database tables. This task uses the following sequence of steps:

• Close database
• Disable journalling
• Backup database
• Open database for exclusive access
• Drop indices
• Delete from tables
• Load data
• Create indices
• Enable journalling
• Backup database
• Open database for global access

The following notes indicate which of the above steps are executed under which circumstances:

• If a load procedure is used, the delete from tables and load data steps are replaced by the execution of the load procedure.
• If journalling is enabled during the load, the disable journalling, drop indices, create indices and enable journalling steps are not used.

Define Rdb critical logicals.

Creates a miniature version of a database (i.e. contains logical but no physical schema). The resultant database will have a filename of appl.RDB and will be located in the runtime directory.

Start a database monitor process.

Move parts of a database from one disk area to another. This function is not fully implemented yet.

Open the database using RMU/OPEN. This should be executed as the last step.

Recover the database from a .RBF file using RMU/RESTORE and/or RMU/RECOVER. The .RDF file must exist before the restoration can begin. Note that the database is dropped before being restored using an SQL DROP DATABASE command. If the database drop fails, the database is not recovered.

Reopen the database using RMU/CLOSE followed by RMU/OPEN.

Restore the database from a .RBF file using RMU/RESTORE. The .RBF file must exist before the restoration can begin. Note that the database is dropped and its after image journal files deleted before being restored using the same sequence as the DROP step. If the database drop and subsequent attempt to delete its files fails, the database is not restored.

Secure the database.

Start journalling on a database.

Stop journalling on a database.

Unload data from one or more database tables.

Unsave the DBAMNU context by deleting all the DBA_xxx_yyy symbols. This can be useful when the current saved answers are no longer appropriate. After this task has completed, all questions will revert to their defaults answers.

Update the database schema to the latest version. The scripts used by this task have a name of the form appl_DBA_UPDATE_Vmmmm_TO_Vnnnn.SQL (or .COM) where mmmm is the four digit current version code and nnnn is the four digit update version code. An example of a version code is V0100 for V1.0 and V0312 for V3.12.

Verify the consistency of the database using an RMU/VERIFY command.

Invokes the DBATOOLS utility.

Format

DBATOOLS [sub-command]

This section provides information about each of the subcommands you can use with the DBATOOLS command.

Transfers control from your current process (which then hibernates) to the specified process.

The DBATOOLS ATTACH and DBATOOLS SPAWN commands cannot be used if your terminal has an associated mailbox.

Note that this command is only available for users with DCL access.

Format

DBATOOLS ATTACH [process-name]

Parameters

process-name

Specifies the name of a parent process or spawned subprocess to which control passes. The process must already exist, be part of your current job, and share the same input stream as your current process. However, the process cannot be your current process or a subprocess created with the /NOWAIT qualifier.

Process names can contain from 1 to 15 alphanumeric characters. If a connection to the specified process cannot be made, an error message is displayed.

Exactly one of the process-name parameter or /IDENTIFICATION or /PARENT qualifiers must be specified. No combinations are allowed.

Qualifiers

/IDENTIFICATION=pid

Specifies the process identification (PID) of the process to which terminal control will be transferred. Leading zeros can be omitted.

Exactly one of the process-name parameter or /IDENTIFICATION or /PARENT qualifiers must be specified. No combinations are allowed.

/PARENT

Indicates that you want to attach to the parent process of your current process. If you did not access the DBATOOLS utility by using the SPAWN command, an error message is displayed.

Exactly one of the process-name parameter or /IDENTIFICATION or /PARENT qualifiers must be specified. No combinations are allowed.

Examples

$ DBATOOLS ATTACH JONES_2
      

The ATTACH command transfers the terminal's control to the subprocess JONES_2.

DBATOOLS> ATTACH/IDENTIFICATION=30019
      

The ATTACH command switches control from the current process to a process having the PID 30019. Notice that because the /IDENTIFICATION qualifier is specified, the process-name parameter is omitted.

Extracts source definitions from an Oracle Rdb database.

Format

DBATOOLS EXTRACT/SOURCE class-name[,...] [object-name[,...]]

Parameters

class-name[,...]

Specifies the classes for which definitions should be extracted. The extractions occur in the order specified. Valid classes include:

• Constraints
• Domains
• Functions or Routines
• Indices or Indexes
• Outlines
• Storage_Maps
• Tables
• Triggers
• Views

object-name[,...]

Specifies the objects for which definitions should be extracted. The object names may contain OpenVMS wildcards. The extractions occur in the order specified. No occlusion occurs i.e. if two wildcard object names are specified and some objects match both values, the definitions of those objects are extracted twice.

Qualifiers

/CLUES=(name=value[,...])

/NOCLUES (Default)

Specifies clues to apply in generating te output. The following table lists the clues currectly supported:

Clue Name	Value and Usage
ATTACH	Include an ATTACH FILENAME statement at the beginning of the generated SQL script.
EXIT	Include an EXIT statement at the end of the generated SQL script.
NODE_SIZE	An integer specifying the node size to use with sorted indices.
PERCENT_FILL	An integer specifying the fill percentage to use with sorted indices.
STORE	A string specifying the store clause to use with indices. The cluas doesn't incluse the store word eg. /CLUES=(STORE="in my_area") would result in the clause store in my_area to be used.
[NO]VERIFY	Include a VERIFY or NOVERIFY statement at the beginning of the generated SQL script.

By default, /NOCLUES is assumed.

/COMMENT="text"

Specifies the comment to be placed in the header of each generated source.

/DATABASE=database-root

Specifies the root file of the database from which definitions should be extracted.

By default, /DATABASE=SQL$DATABASE is assumed.

/EXCLUDE=(name[,...])

/NOEXCLUDE (Default)

Specifies whether certain objects should be excluded. Standard OpenVMS wildcards are supporterd.

By default, /NOEXCLUDE is assumed.

/HEADER

/NOHEADER (default)

Specifies that a comment block is included for each generated object source.

/LANGUAGE[=name[=option]]

Specifies the language in which the extracted definition should be formatted. Some languages also support an additional option. Valid languages include:

Language	Ooption	Usage
CDO		Generate a CDD/Repository source which creates an equivalent to a database object. Valid for domains and tables only.
SDML		Generate a DECdocument source which describes a database object. Valid for domains, tables, triggers and views only.
SQL	CREATE	Generate an SQL script which creates the matching database objects. This is the default language and option.
	DROP	Generate an SQL scrip which drops the matching database objects.
	DUPLICATE	Generate an SQL script whish finds duplicates for a non unique index.
SQLMOD		Generate an SQLmodule for a table or index.

By default, /LANGUAGE=SQL=CREATE is assumed.

/LOG

/NOLOG (default)

Displays the file specification of each new file created as the command executes.

/ORDER_BY={NAME|POSITION}

Specifies which order columns are listed in when the order doesn't affect the functionality of the result.

Using /ORDER_BY=NAME indicates that columns are listed in alphabetic order. This formt is useful when comparing the meta-data of two databses.

Using /ORDER_BY=POSITION indicates that columns are listed in the order in which they are stored. This is useful when dealing the meta-data related to unloaded data (i.e. extracted using the RMU/UNLOAD command.

By default, /ORDER_BY=NAME is assumed.

Note that this qualifier is ignored when extracting an index definition as columns in an index are always orderd by their position.

/OUTPUT[=output-file-spec]

/NOOUTPUT

Specifies the output file specification for the command.

By default, /OUTPUT=SYS$OUTPUT is assumed. The /NOOUTPUT qualifier means that no output will be produced by the command.

/PREFIX=value

/NOPREFIX

Specifies a prefix to be used for certain names such as the source file name for a database object.

By default, the current context application code is used.

/SEPARATE={CLASSES|OBJECTS}

/NOSEPARATE (Default)

Specifies whether and and what points the output should be placed in separate files.

By default, /NOSEPARATE is assumed which indicates that all definitions are placed in a single output file.

Using /SEPARATE=CLASSES indicates that a separate output file is created for each class. All the object definitions for that class are placed in a single output file.

Using /SEPARATE=OBJECTS indicates that a separate output file is created for each object definition.

/TRANSACTION=(option[,...])

/NOTRANSACTION (Default)

Specifies whether set transaction and commit work statements should be included in the output. This qualifier is only valid if /LANGUAGE=SQL is specified or implied.

---

Previous

Next

Contents

Index