Try OpenEdge Now
skip to main content
Database Administration
Reference : Other Database Administration Utilities : DBTOOL utility
 

DBTOOL utility

Diagnostic tool that identifies possible record issues and fixes SQL Width violations.

Syntax

dbtool db-name

Parameters

db-name
Name of the database to be scanned.
When you enter the DBTOOL utility, the DBTOOL main menu appears as shown in the following figure.
Table 107. DBTOOL main menu
                     DATABASE TOOLS MENU - 11.4
                     --------------------------

                1. SQL Width & Date Scan w/Report Option
                2. SQL Width Scan w/Fix Option
                3. Record Validation
                4. Record Version Validation
                5. Read or Validate Database Blocks
                6. Record Fixup
                7. Schema Validation
8. Disable Object Locking Protection
                9. Enable/Disable File Logging
               10. Index Space Validation
               11. Index Space Fixup
12. Schema Fixup

                Q. Quit

                Choice:
The menu options provide the following functions:
*SQL Width & Date Scan w/Report Option — Reports on the following SQL values:
*_Field._Width
*year_value<0
*year_value>9999
*Array Width (applicable only to DataServers)
*Max ArrayWidth (applicable only to DataServers)
In the generated report, three asterisks (***) in the Error column indicate SQL width or date violations.
See Running DBTOOL for a description of the output generated with different logging levels.
*SQL Width Scan w/Fix Option — Scans for width violations over the specified percentage of the current maximum width, and increases SQL width when necessary. The SQL width calculation for OpenEdge SQL and OpenEdge DataServers are the same in all cases except for CHARACTER, RAW, and DECIMAL extent fields calculations in OpenEdge DataServers. For more information about the migration requirement differences between OpenEdge SQL and OpenEdge dataservers, see the Display prompt discussion in the next sub-section of this topic.
In this menu option, you are prompted to enter a number indicating the percentage above the current maximum width to allocate for record growth. For example, if the current maximum width of a field is 100, and you specify 10 percent for growth, DBTOOL checks the SQL Width of the field, and if it is less than 110, increases it to 110. If SQL Width is larger than the field's current maximum width plus the percentage for growth, SQL Width is not changed.
See Running DBTOOL for a description of the output generated with different logging levels.
*Record Validation — Compares the physical storage of the record to the schema definition and reports discrepancies.
*Record Version Validation — Performs record validation before and after upgrading the schema version of a record. This option is used to test, through record validation, before and after upgrading the schema version of a record in memory, if a schema upgrade will succeed when an out of date record is next accessed by a client request at runtime. The first check compares the record to the current schema definition in the record header. After that check completes, if the table has a newer definition of the schema than the record, the record schema is updated, and then the physical record is compared to the new definition.
Note that DBTOOL does not commit the records updated to the current schema version to the database, it only makes a comparison.
*Read or validate database block(s) — Validates the information in the database block header. There are three levels of validation:
*Reads the block only
*Conducts physical consistency record checks at runtime (except record overlap check)
*Conducts physical consistency record checks at runtime
This option can be invoked by choosing to validate either all record blocks in one area or all record blocks in all areas.
Note: The validation process will report the first error in a block then proceed to the next record block. Details of the errors encountered will be recorded in the database .lg file.
*Record fixup — Scans records for indications of possible corruption.
*Schema Validation — Checks for inconsistencies in the database schema. This option currently identifies errors in schema records for word indexes. If an error is detected, this option reports the index number and recommends rebuilding that index.
*Enable/Disable File Logging — Toggles the redirection of the tool output to a file named dbtool.out. DBTOOL writes this file to your current working directory.
*Index Space Validation — Checks for index space allocation errors.
*Index Space Fixup — Fixes any errors discovered with Index Space Validation.
*Schema Fixup — Fixes rare types of schema corruption. Choose one of the following:
*SQL View Index Cleanup — Fixes schema corruption that occurs when there are physical indexes for SQL Views by removing these invalid indexes.
*_User Records Missing Fields Fixup — Fixes a problem with databases converted using CONV1011 that have an _user table with greater than 65536 records. The _user table is missing new fields after the conversion.
*.

Notes

*DBTOOL is a multi-threaded utility. The connection type you specify when running the utility determines the number of threads DBTOOL will run. Because each thread uses a database connection, be aware of what the broker startup parameter (-n) is set to. Specifying 1.5*(number of CPUs) as the number of threads to run DBTOOL with is usually adequate.
*DBTOOL sends output to .stdout. To redirect output to a file, use the redirection symbol, as shown:
dbtool db-name 2 > filename.out
If you decide to redirect output after entering DBTOOL, select Enable/Disable File Logging from the DBTOOL menu. This option redirects the output to a file named dbtool.out. DBTOOL writes this file to your current working directory.
*DBTOOL does not fix date errors, it only identifies them. To fix date errors, use the Data Dictionary or Data Administration tool to modify the fields that contain incompatible date values.
*The Schema Fixup option addresses a rare type of schema corruption that occurs when there are physical indexes for SQL Views. Physical indexes for a SQL view serve no purpose in the database and should not exist. Rarely, such an index can cause errors in database utilities performing scans, such as PROUTIL IDXBUILD. The Schema Fixup option removes these invalid indexes. If a database has physical indexes for SQL views, the Schema Validation option of DBTOOL reports these indexes as an error, as shown:
ERROR: Invalid _object-associate 0 for _StorageObject 2431
ERROR: _StorageObject 2431 belongs to a SQL View
Index 2431 is orphaned and should be deleted.
After detecting the error, the Schema Validation option of DBTOOL directs you to run the Schema Fixup option, as shown:
SQL View Index errors found: 1

Please run the Schema Fixup option SQL View Index Cleanup.
* Running DBTOOL