SCI provides DBA support to customers worldwide – in Asia, Europe and the U.S.A. As you can imagine, we have seen many styles of maintaining databases and systems, some that work and some that are very risky or inefficient. During the initial implementation of our services, we provide a complete audit and review of the customer’s database environment to determine the optimal configuration, ensuring both the safety and efficiency of the database. From our findings, we share with you optimizations that were overlooked or risks that were never exposed!

WRONG PLACEMENT MAY SPELL D-I-S-A-S-T-E-R

We have found RUJ files that were stored on the same device as the database backup files and AIJ files. This is VERY risky!! If the disk that contains the RUJs fails, the database would be non-recoverable, requiring the database to be restored from a prior backup. Now we need the database backup file. Oops!! Sorry!!! The database backup file was on the same device that crashed and burned with the RUJs.

To recover from this disaster, the most recent available backup file (which hopefully is on tape) has to be located and restored before the database can be restored. This backup file may be quite old. After restoring the database from this backup, all AIJs since this backup would also have to be located, restored to disk and applied to the database to make it consistent. This is a long and risky recovery process...and time means money!

RUJ files are critical files, and must be handled with the same care as database storage-area files. Loss of a single RUJ file may result in an unrecoverable database.

We strongly recommend that clients create an appropriate directory for the RUJ files, then define the logical name RDMS$RUJ (for Rdb) and DBM$RUJ (for DBMS) in the startup file or the site equivalent to point to this directory. If your environment contains multiple databases, you may specify the location for RUJ files for each database by using "SQL ALTER DATABASE FILENAME<root>RECOVERYJOURNAL (LOCATION IS <location>)" for Rdb or  “DBO/MODIFY<root>/RECOVER=<location>” for DBMS. SCI recommends locating the RUJ files on shadowed (or mirrored) devices that do not contain AIJ files or database backup files. Remember, the database you save may be your own!!!

OPTIMIZING BY EXPERIENCE (NO, IT’S NOT MAGIC)

Prior to installing our services, when one of our clients verified its database, its process ran for over 3 days – so long that this job was not part of their regular maintenance schedule (risky).

After installing our services, verifying the database weekly now takes only 2 hours! A savings of 94 hours and a 98% time reduction. Not a bad start. But, you ask, “What’s missing from this verification?” Nothing. In fact, our verification method provides a more complete verification than was originally performed. We make optimal use of the new features and optimizations available in Rdb and DBMS.

The verification was not our only success. In addition, the customer’s database backups ran for 4 hours – SCI’s finished in only 30 minutes. Although only a 75% time reduction (not the 98% reduction we achieved with the verification), it was still quite respectable.

Another important maintenance task is monitoring the utilization of all storage areas. The RMU/ANALYZE and DBO/ANALYZE tools provide the information needed. Again, our experience paid off. Our customer’s routines ran for over 24 hours (when limited to only 3 major areas). But we completed the required usage analysis in only 33 minutes.

Our optimizations have given our customers several hours of valuable compute time on their systems, which they are happy to use for their application rather than “maintenance overhead” tasks. Our methodologies ensure the integrity and recoverability of their database environment, preventing unnecessary risks or disasters!

You might question how we could do that. Well, it is not magic and it is not shortcuts. We do not circumvent safety for speed. We have been working with Rdb and DBMS for many years and our tools are optimized to take advantage of every feature of Rdb and DBMS and the operating system. We know how to make Rdb and DBMS run fast, very fast!