Rdb Controller VMS CD RELEASE NOTES __________________________________________________________________ DBAnalyzer for Rdb Version 5.3 __________________________________________________________________ This version of the tool is specifically for Rdb 7.1 on Alpha AXP systems. Internal buffer space has been increased in order to process larger and more complex databases with minimal customization changes. Some cosmetic corrections were made to report/screen displays. The Kanji character set for stored data is now processed and displayed correctly on the appropriate language display, although screens and reports still use English "headings" and descriptive text. Make sure the Rdb character set logical is set to the appropriate value "define RDB$CHARACTER_SET DEC_KANJI". Basic functionality is the same as in V5.2. Major changes to functionality are not expected to be released until V6 is released. __________________________________________________________________ DBAnalyzer for Rdb Version 5.2 __________________________________________________________________ Changes Since Last Release: 1) Directories Handled Correctly Some previous versions of DBAnalyzer would not run correctly unless the user was in FREND$DBA$HOME and would not leave the user in the original directory after DBAnalyzer finished. DBAnalyzer 5.2 can be run from any directory and leaves the user in their original directory after interactive execution is completed. 2) Data Structure Conflict Error With single file databases, some versions of DBAnalyzer would abort with a data structure conflict error. This is now fixed. 3) Key Already Exists Error With some Rdb 7 databases, DBAnalyzer aborted during execution with a 'Key already exists' error. This problem has been corrected. 4) Tables with Very Long Comments Previously DBAnalyzer would abort when loading Rdb metadata if the table had a comment longer than 500 characters. 5) Triggers and Constraints with a Large Number of Lines. Prior versions of DBAnalyzer sometimes incorrectly reproduced triggers or constraints if the individual trigger or constraint had 100 or more lines. 6) Table and Column Names No Longer Truncated Earlier versions of DBAnalyzer would sometimes truncate a table or column name of 31 characters to 30 characters. This problem has been fixed. Other Notes: Reporting Domains Reporting DOMAINS in the database will require additional time. It is advised that the FULL report or any report which includes domains be run in batch. Abbreviations for Non-English Languages For those users applying DBAnalyzer to databases defined with a language other than English, a version of DBAnalyzer's abbreviation file for your language may be provided. Abbreviation files have been provided for the following languages: FRANCAIS, DEUTSCH, NEDERLANDS, and ENGLISH. For example, if users in France want to use French abbreviations, they can do the following: $ EDIT FREND$DBA$HOME:DBA.COM - search for "ENGLISH" - comment out the line 'FREND_LANGUAGE :== "ENGLISH"' - uncomment the line 'FREND_LANGUAGE :== "FRANCAIS"' - exit and save the file You only need to perform this step once and DBAnalyzer will use the French abbreviation file for every subsequent execution. Similar steps can be performed for the other languages mentioned above. 132-Column Reports All reports except SUMMARY will require that you print the reports in 132-column mode. Before printing, your printer needs to be set for compressed print. Maintenance Logicals Following are logicals which can be used to override some of DBAnalyzer's default values or to get more detailed output. These logicals can be set before DBAnalyzer is run to affect selection ranges for a cardinality distribution in DBAnalyzer's report output. FREND$CARD$1 Upper range #1 for a cardinality distribution of tables and indices. Default: 99 FREND$CARD$2 Upper range #2 for a cardinality distribution of tables and indices. Default: 249 FREND$CARD$3 Upper range #3 for a cardinality distribution of tables and indices. Default: 499 FREND$CARD$4 Upper range #4 for a cardinality distribution of tables and indices. Default: 999 FREND$CARD$5 Upper range #5 for a cardinality distribution of tables and indices. Default: 2499 FREND$CARD$6 Upper range #6 for a cardinality distribution of tables and indices. Default: 4999 FREND$CARD$7 Upper range #7 for a cardinality distribution of tables and indices. Default: 9999 FREND$CARD$8 Upper range #8 for a cardinality distribution of tables and indices. Default: 49999 FREND$CARD$9 Upper range #9 for a cardinality distribution of tables and indices. Default: 99999 FREND$CARD$10 Upper range #10 for a cardinality distribution of tables and indices. Default: 999999 Note All tables and indices with a cardinality greater than FREND$CARD$10 are reported in a final range. __________________________________________________________________ DBTune for Rdb Version 5.3 __________________________________________________________________ This version of the tool is specifically for Rdb 7.1 on Alpha AXP systems. Internal buffer space has been increased in order to process larger and more complex databases with minimal customization changes. Some cosmetic corrections were made to report/screen displays. The Kanji character set is now processed and displayed correctly, although screens and reports still use English "headings" and descriptive text. The use of the depricated "rmu/analyze/cardinality/update" has been dropped. Basic functionality is the same as in V5.2. Major changes to functionality are not expected to be released until V6 is released. Note that there is a documented problem with Oracle SQLNet for Rdb and the import/export tuning method. These is an incompatibility between the import/export command process itself, and occurs with ANY use of this command on such systems. The Oracle recommended workaround is documented on the www.aliconsultants.com web site. Basically, SQLNet for Rdb must be de-installed, internal tables dropped, the scripts generated and executed, and then the SQLNet reinstalled. To increase import/export tuning speed, insert "batch update" in the import SQL statement used in tuning. This prevents writing to the RUJ file. Also assign "set RMS_DEFAULT/EXTEND_QUANTITY=50000" before the export executes to reduce the file extension time (the default extensino is 2 blocks). If you are tuning a system that was created using RDO syntax, DBTune WILL NOT generate proper SQL for restoring views since the internally stored "creation text" in Rdb is not in SQL92. However, the "RMU/extract/language=RDO" command can give you the RDO syntax for views, etc that you may need in restoring these to the database. __________________________________________________________________ __________________________________________________________________ DBTune for Rdb Version 5.2 __________________________________________________________________ Changes Since Last Release: 1) Directories Handled Correctly Some previous versions of DBTune would not run correctly unless the user was in FREND$DBTUNE$HOME and would not leave the user in the original directory after DBTune finished. DBTune 5.2 can be run from any directory and leaves the user in his or her original directory after interactive execution is completed. 2) Parsing Errors Corrected Previous versions of DBTune that ran with Rdb 7.0-1 and later parsed incorrectly which could lead to incorrect AIJ assignments and erroneous global buffers. Parsing problems have been corrected in DBTune 5.2. 3) Data Structure Conflict Error With single file databases, some versions of DBTune would abort with a data structure conflict error. This is now fixed. 4) Key Already Exists Error With some Rdb 7 databases, DBTune aborted during execution with a 'Key already exists' error. This problem has been corrected. 5) Tables with Very Long Comments Previously DBTune would abort when loading Rdb metadata if the table had a comment longer than 500 characters. This has been fixed in DBTune 5.2. 6) Triggers and Constraints with a Large Number of Llines Prior versions of DBTune sometimes incorrectly reproduced triggers or constraints if the individual trigger or constraint had 100 or more lines. DBTune 5.2 processes these triggers and constraints correctly. 7) Table and Column Names No Longer Truncated Earlier versions of DBTune would sometimes truncate a table or column name of 31 characters to 30 characters. This problem has been fixed. 8) File Size Estimates File size estimates in DBTune's Review and Guide report sometimes were negative for very large databases. This problem has been corrected. Other Notes: Temporary Tables In Rdb 7.0 and later, data in temporary tables is NOT preserved between sessions. Any temporary tables tuned with DBTune 5.2 will be empty after tuning. Mulltiple FREND$DBTUNE$SCRATCH logicals In order to generate scripts for MULITPLE databases at the SAME TIME, each executing image of DBTune should have a different FREND$DBTUNE$SCRATCH logical defined and pointing to a different directory. This eliminates the "possibility" of one job deleting the files needed by another during the "clean up" phase. Former Usage of RDO May Cause SQL Scripts to Fail If you choose to use RMU/UNLOADs and RMU/LOADs to tune selected tables of a database, items which are defined on those tables (views, constraints, triggers, comments) must be dropped and then re-created when the tables are dropped and re-created. If any views, constraints, or triggers were previously defined with RDO, the tuning scripts may fail when the items are re-created using SQL statements (DBTune uses the original definition of the item to re-create it). If database items were formerly created using RDO, the user should review the SQL scripts generated by DBTune BEFORE executing the MAIN_DRIVER command file to ensure that no syntactical violations exist for views, constraints, and/or triggers. Cannot Access a Database Over a Network Using DBTune DBTune cannot be used to generate SQL scripts for a database over the network because of limitations of Rdb and RMU. Scripts can be generated on a local node, however, and then copied over the network to be executed against a database on a remote node. Abbreviations for Non-English Languages For those users applying DBTune to databases defined with a language other than English, a version of DBTune's abbreviation file for your language may be provided. As of DBTune V3.0, abbreviation files have been provided for the following languages: FRANCAIS, DEUTSCH, NEDERLANDS, and ENGLISH. For example, if users in France want to use French abbreviations, they can do the following: $ EDIT FREND$DBTUNE$HOME:DBTUNE.COM - search for "ENGLISH" - comment out the line 'FREND_LANGUAGE :== "ENGLISH"' - uncomment the line 'FREND_LANGUAGE :== "FRANCAIS"' - exit and save the file The user only needs to perform this step once and DBTune will use the French abbreviation file for every subsequent execution. Similar steps can be performed for the other languages mentioned above. Maintenance Logicals Following are logicals which can be used to override some of DBTune's default values or to get more detailed output. It is generally recommended that these logicals NOT be changed except under the advice of a support person from DB Solutions. FREND$FAST$COMMIT If AIJ journaling is enabled, this logical is used to determine if Fast Commit processing should be enabled. Valid values: "Y" - enable Fast Commit "N" - do NOT enable Fast Commit Default: "N" - do NOT enable FREND$IDX$DUP$LIM Sets the upper limit for flagging excessive index duplicates in the REVIEW_AND_GUIDE report. Any index with more than this number of average duplicates will be printed to the report. Valid values: 0 to 100000 Default: 10 FREND$TARGET$BUFFER Sets a "target" buffer size (in blocks) for DBTune to tune towards. For example, if the disk blocking factor for a database system has been set to 18 blocks, the user may wish for the database buffer size to match the disk blocking factor to increase performance. Valid values: 6 to 64 Default: 12 FREND$BUFFER$PAGE Points to a data file used by DBTune to determine "valid" buffer size and page size combinations. See the file BUFFER_PAGE.DAT located in the FREND$DBTUNE$HOME directory for more information on how this logical is used. Valid values: A valid file specification Default: FREND$DBTUNE$ HOME:BUFFER_ PAGE.DAT FREND$BIAS$SCALE Points to a data file used by DBTune to adjust page sizes and sorted index node sizes during tuning calculations. The adjustments are based on the individual access bias settings for database tables. See the file BIAS_SCALE.DAT located in the FREND$DBTUNE$HOME directory for more information on how this logical is used. Valid values: A valid file specification Default: FREND$DBTUNE$ HOME:BIAS_ SCALE.DAT FREND$SEGSTR$MB Sets a threshold (in megabytes) to determine how many storage areas are needed to store segmented strings. This logical is only used for SQL EXPORT/IMPORTs. For example, assume that for a particular database, segmented string storage requires 3 gigabytes of disk space. How many storage areas do you wish this to be distributed over and how large do you wish those areas to be? If this logical is assigned the value 512 megabytes, then at least six 'LIST' storage areas will be created with a maximum size of 512 megabytes each. If the segmented string storage requirements for a database are high, this logical can be reduced to create more 'LIST' storage areas to further distribute them across available disks. If segmented string storage requirements are low, this value can be left at the default value to reduce the number of storage areas. This logical sets the upper limit for how large a single 'LIST' storage area can be. Valid values: 10 to 1024 megabytes Default: 256 FREND$DISKIO$RATE Sets the "standard" disk I/O rate used to calculate the amount of time required to tune a database using RMU UNLOAD/LOADs. Valid values: 10 to 99999 IOs_per_second Default: 30 IOs_per_second FREND$SYS$LOAD Sets the system usage level for the machine on which tuning will occur. If system usage will be heavy during database tuning, this value can be increased. If the system load will be light, this value can be decreased. Valid values: 1.0 to 3.0 where 1.0 = Low usage and 3.0 = High usage Default: 2.0 = Medium system usage FREND$IMPORT$DEBUG$FLAG Used for debugging views, constraints, and triggers as they are read into DBTune. Debug files are named with a ".*DEBUG" extension and are placed in the directory assigned to the SQL_DIR parameter. Valid values: "N", "Y" Default: "N" FREND$STOR$BUFFERS Number by which local buffers are incremented per storage area. Default: 2 FREND$IDX$BUFFERS Number by which local buffers areincremented per write-biased sorted index. Default: 3 FREND$COMPUTED$BY$FLAG If you wish to tune a databaseusing RMU UNLOAD/LOADs and some of the database tables contain 'COMPUTED BY' columns, the RUM/UNLOAD commands and the RMU/LOAD commands must be altered. Assigning a value of "Y" to this logical prior to running DBTune will cause DBTune to generate the necessary changes. Valid values: "N", "Y" Default: "N" FREND$VARCHAR$COMPRESSION Used to compress large "VARCHAR" fields when tuning. All VARCHAR fields greater than or equal to FREND$COMPRESSION$CUTOFF bytes will be compressed by the value entered for this logical in DBTune's calculations. Valid values: 1% to 100% Default: 33% FREND$CHAR$COMPRESSION Used to compress large "CHAR" fields when tuning. All CHAR fields greater than or equal to FREND$COMPRESSION$CUTOFF bytes will be compressed by the value entered for this logical in DBTune's calculations. Valid values: 1% to 100% Default: 50% FREND$COMPRESSION$CUTOFF Used to set the minimum size (in bytes) of a "CHAR" or "VARCHAR" field for which FREND$CHAR$COMPRESSION and FREND$VARCHAR$COMPRESSION will apply. For example, if this logical is assigned the value of 1024, no "CHAR" or "VARCHAR" fields with a length of less than 1024 will be affected by the compression values above. Valid values: 100 to 65269 bytes Default: 256 bytes FREND$BYPASS$FLAG If this logical is defined PRIOR to running DBTune, you can override certain features or error checking generated by DBTune in its SQL and DCL scripts. Following are the values that can be assigned to the FREND$BYPASS$FLAG logical, they can be assigned either singly ("D" or "L") or combined ("DLR", "A42", etc): "D" - Causes the MAIN_DRIVER procedure to skip disk space checks for the RMU/BACKUP and EXPORT files. Following is a scenario where this might be utilized: If you are using a volume set made up of multiple disks, the disk checks in MAIN_DRIVER will only detect the space on the first disk of the volume set. If this is not ample for the backup or export files, MAIN_DRIVER will exit even though the volume set may have more than enough space. By setting the BYPASS logical to "D", you will cause this space check to be skipped. "L" - Causes the MAIN_DRIVER procedure to skip disk space checks for the SQL LOG file. During execution of the MAIN_DRIVER, the device on which the SQL LOG file is placed is checked for adequate disk space. If there is insufficient space, the MAIN_DRIVER will halt. By setting the BYPASS logical to "L", you will cause this space check to be skipped, for reasons similar to those expressed for the "D" setting above. "R" - Causes the MAIN_DRIVER procedure to use an unparsed version of the Rdb directory in generated SQL scripts, when no DBDISK entries have been added via the DBTune parameter file. As of V3.0 of DBTune, all logicals and directories are parsed to their raw device names to avoid confusion between PROCESS and SYSTEM logicals. However, if you are using CONCEALED device names and wish to create ALL the database files on the same concealed device, you can bypass the logical parsing performed by DBTune. The location that will be used to place database files in this case will be assigned to the logical FREND$RDB$ORIG and will be displayed by DBTune. "A" - Causes the MAIN_DRIVER procedure to skip the RMU/BACKUP of the AIJ (After-Image Journal). If tuning an Rdb V6.0 or higher database with multiple AIJs using RMU UNLOADS/LOADS, sometimes a backup of the AIJ is required to re-enable AIJs after tuning. If the user wishes to skip this AIJ backup, the BYPASS logical can be set to "A." Be warned, however, that this may cause the post-tuning SQL scripts to fail. "42" - If the version of Rdb cannot be determined and you wish for DBTune to assume that the database is an Rdb 4.2 database, set the BYPASS logical to "42". Otherwise, DBTune will use the correct Rdb version setting or will assume that it is working with an Rdb 6.0 or higher database. Do not set this value without first consulting with Customer Support at The Database Solutions Company. The following logicals can be set before DBTune is run to affect selection ranges for a cardinality distribution in DBTune's report output. FREND$CARD$1 Upper range #1 for a cardinality distribution of tables and indices. Default: 99 FREND$CARD$2 Upper range #2 for a cardinality distribution of tables and indices. Default: 249 FREND$CARD$3 Upper range #3 for a cardinality distribution of tables and indices. Default: 499 FREND$CARD$4 Upper range #4 for a cardinality distribution of tables and indices. Default: 999 FREND$CARD$5 Upper range #5 for a cardinality distribution of tables and indices. Default: 2499 FREND$CARD$6 Upper range #6 for a cardinality distribution of tables and indices. Default: 4999 FREND$CARD$7 Upper range #7 for a cardinality distribution of tables and indices. Default: 9999 FREND$CARD$8 Upper range #8 for a cardinality distribution of tables and indices. Default: 49999 FREND$CARD$9 Upper range #9 for a cardinality distribution of tables and indices. Default: 99999 FREND$CARD$10 Upper range #10 for a cardinality distribution of tables and indices. Default: 999999 Note All tables and indices with a cardinality greater than FREND$CARD$10 are reported in a final range. Multischema Databases Not Supported DBTune V5.x does not currently support Rdb databases with the MULTISCHEMA attribute turned on. Worm Areas Not Supported DBTune V5.x does not currently support storage areas with the WRITE ONCE (WORM) qualifier. Snapshot Files May Extend During RMU/LOADS When tuning a database using RMU UNLOAD/LOADs, snapshots may become extended. Snapshot files are initially allocated by DBTune based on the size of the .RDA files and parameter entries you make. When an RMU/LOAD is performed after tuning, however, the snapshot files may grow larger than their initial allocation. This is a common occurrence due to the way in which snapshot files work. To reset the snapshot files, simply create an SQL script for the database that respecifies the original allocation for each storage area. For example: SQL>> ALTER DATABASE FILENAME database_name cont>> ALTER STORAGE AREA area_name_1 cont>> SNAPSHOT ALLOCATION IS nnn PAGES cont>> ALTER STORAGE AREA area_name_2 cont>> SNAPSHOT ALLOCATION IS nnn PAGES cont>> etc... ; Rdb License If using RMU UNLOAD/LOADs to tune a database, you must have an interactive or development license for Rdb/VMS. If you only have a RUNTIME license for Rdb/VMS, you can only tune your database via SQL Export/Import. 512 File Limit for Rdb Some older versions of Rdb/VMS (V4.1, V4.2) have an internal file limit of 512 files that can be opened simultaneously. This limitation was removed for higher versions of Rdb (V4.2a and higher). However, if you have an older version of Rdb, you will want to set the SA_MIN_CARD parameter so that the resulting tuned database has less than 250 storage areas (each storage area has 2 files). Otherwise, SQL scripts may fail. Major Changes Since the Previous Release (Version 4.0) Depending upon the version of Rdb that you were running, previous versions of DBTune would not always report properly the journaling (or AIJ) status. This problem has been fixed. For AXP systems, a problem calculating system memory pages for global buffers has been corrected. SPAM page calculations for storage areas with large allocations have been improved. On AXP systems, the number of system memory pages recommended for global buffers was far too large (by a factor of 16). This problem has been fixed and the recommended number of memory pages for global buffers is now correct on both VAX and AXP. On both VAX and AXP systems, for storage areas with larger allocations, the calculation for the number of SPAM pages did not work correctly and resulted in too many pages being allocated. The number of SPAM pages needed is now calculated correctly. _________________________________________________________________________ DBXAct for Rdb Version 5.0 _________________________________________________________________________ DBXAct 5.0 extends DBXAct functionality to the following versions and patch levels of Rdb: 6.1-04 6.1-1 6.1-11 6.1-12 6.1-13 7.0-0 7.0-01 7.0-1 7.0-11 7.0-12 for both standard and multiversion Rdb on both VAX and AXP. _________________________________________________________________________ DBXAct for Rdb Version 5.1 _________________________________________________________________________ DBXAct 5.1 extends DBXAct functionality to the following versions and patch levels of Rdb: 6.0-16 M only on Vax 6.1-13 6.1-14 7.0-10 M only on axp 7.0-12 7.0-13 7.0-14 7.0-15 7.0-16 on axp 7.0-2 on axp (M on Vax) 7.0-21 S only 7.0-3 7.0-31 7.0-4 7,0-5 7,0-6 7,0-61 7.0-62 7.0-63 for both standard and multiversion Rdb on both VAX and AXP unless noted. If support is required for a version not listed here, contact ALI for a special build. __________________________________________________________________ DBXact for Rdb Version 5.2 __________________________________________________________________ This version of the tool is specifically for Rdb 7.1 on Alpha AXP systems. Internal buffer space has been increased in order to process larger and more complex databases with minimal customization changes. Some cosmetic corrections were made to report/screen displays. Basic functionality is the same as in V5.1. Major changes to functionality are not expected to be released until V6 is released. A complete list of supported version of Rdb for all versions of DBXact is available from the "Tool version locator" link off www.aliconsultants.com. __________________________________________________________________