C:\mirror\040226AC.MLG - renamed mirror log file from 3rd backup G:\bkup\test9.db - backup database file from 1st backup G:\bkup\040317AA.LOG - backup transaction log file from 1st backup G:\bkup\040317AB.LOG - backup transaction log file from 2nd backup G:\bkup\040317AC.LOG - backup transaction log file from 3rd backup Note: The BACKUP DATABASE command renames and restarts the current mirror log file in the same way it does the current transaction log file, but it does not make a backup copy of the mirror log file. That’s okay: The mirror log files are really just copies of the corresponding transaction logs anyway, and three copies are probably sufficient. 9.12.5 Live Log Backup A live log backup uses dbbackup.exe to continuously copy transaction log data to a file on a remote computer. The live log backup file will lag behind the cur - rent transaction log on the main computer, but not by much, especially if the two computers are connected by a high-speed LAN. If other backup files are written to the remote computer, and a live log backup file is maintained, it is possible to use that remote computer to start the database in case the entire main computer is lost; only a small amount of data will be lost due to the time lag between the current transaction log and the live log backup. The following is an example of a Windows batch file that starts dbbackup.exe on the remote computer; this batch file is executed on that com- puter, and the startup folder is remote_test9, the same folder that is mapped to the G: drive on the main computer as described earlier. A local environment variable CONNECTION is used to hold the connection string for dbbackup to use, and the LINKS parameter allows dbbackup.exe to reach across the LAN to make a connection to the database running on the main computer. The -l param- eter specifies that the live log backup is to be written to a file called live_test9.log in the folder remote_test9\bkup. The last parameter, bkup, meets the requirement for the backup folder to be specified at the end of every dbbackup command line. SET CONNECTION="ENG=test9;DBN=test9;UID=dba;PWD=sql;LINKS=TCPIP(HOST=TSUNAMI)" "%ASANY9%\win32\dbbackup.exe" -c %CONNECTION% -l bkup\live_test9.log bkup Here’s what the dbbackup.exe displays in the command window after it has been running on the remote computer for a while; three successive BACKUP DATABASE commands have been run on the main computer, and then some updates have been performed on the database: Adaptive Server Anywhere Backup Utility Version 9.0.1.1751 (1 of 1 pages, 100% complete) (1 of 1 pages, 100% complete) Transaction log truncated by backup restarting (1 of 1 pages, 100% complete) (1 of 1 pages, 100% complete) Transaction log truncated by backup restarting (1 of 1 pages, 100% complete) (1 of 1 pages, 100% complete) Transaction log truncated by backup restarting (1 of 1 pages, 100% complete) (2 of 2 pages, 100% complete) (3 of 3 pages, 100% complete) 386 Chapter 9: Protecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. (4 of 4 pages, 100% complete) Live backup of transaction log waiting for next page When a backup operation on the main computer renames and restarts the current transaction log, the dbbackup.exe program running on the remote computer erases the contents of the live log backup file and starts writing to it again. That’s okay; it just means the live log backup is just a live copy of the current transaction log, which has also been restarted. If the other backup operations, performed on the main computer, write their backup files to the remote com - puter, then everything necessary to start the database is available on the remote computer. Note: It is okay for backup operations, including live log backups, to write output files across the LAN to disk drives that are attached to a different com - puter from the one running the database engine. However, the active database, transaction log, mirror log, and temporary files must all be located on disk drives that are locally attached to the computer running the engine; LAN I/O is not acceptable. In this context, the mirror log is not a “backup file” but an active, albeit redundant, copy of the active transaction log. The next section shows how the files created by the backup examples in this section can be used to restore the database after a failure. 9.13 Restore A restore is the process of replacing the current database file with a backup copy, performing any necessary recovery process to get the database up and run- ning, and then applying any necessary transaction logs to bring the database up to date. Tip: There’s no such thing as an automated restore. You can automate the backup process, and you probably should, but any restore requires careful study and attention. Here is a broad outline of the steps involved in restoring a database, followed by several examples: 1. Don’t panic. 2. Plan ahead: Determine what backup files are available and which ones are going to be used, in what steps and in what order. 3. Rename or copy any file that is going to be overwritten; this is very impor - tant because mistakes are easy to make when restoring a database… especially since Step 1 is often difficult to accomplish. 4. Restore the database and/or apply the transaction log files according to the plan developed in Steps 2 and 3. Example 1: The current database and transaction log are both unusable, and the most recent backup was a full offline image backup of both the database and transaction log as described at the beginning of this section. Here is the Win - dows batch file that performed the backup; it created the backup files that will be used in the restore, G:\bkup\test9.db and G:\bkup\test9.log, plus a backup of the mirror log: Chapter 9: Protecting 387 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. SET CONNECTION="ENG=test9;DBN=test9;UID=dba;PWD=sql" "%ASANY9%\win32\dbisql.exe" -c %CONNECTION% STOP ENGINE test9 UNCONDITIONALLY RENAME G:\bkup\test9.db old_test9.db RENAME G:\bkup\test9.log old_test9.log RENAME G:\bkup\test9.mlg old_test9.mlg IF EXIST G:\bkup\test9.db GOTO ERROR IF EXIST G:\bkup\test9.log GOTO ERROR IF EXIST G:\bkup\test9.mlg GOTO ERROR COPY test9.db G:\bkup\test9.db COPY test9.log G:\bkup\test9.log COPY C:\mirror\test9.mlg G:\bkup\test9.mlg ECHO N | COMP test9.db G:\bkup\test9.db IF ERRORLEVEL 1 GOTO ERROR ECHO N | COMP test9.log G:\bkup\test9.log IF ERRORLEVEL 1 GOTO ERROR ECHO N | COMP C:\mirror\test9.mlg G:\bkup\test9.mlg IF ERRORLEVEL 1 GOTO ERROR ERASE G:\bkup\old_test9.db ERASE G:\bkup\old_test9.log ERASE G:\bkup\old_test9.mlg "%ASANY9%\win32\dbsrv9.exe" -x tcpip test9.db GOTO END :ERROR PAUSE Backup process failed. :END In this situation the best you can hope for is to restore the database to the state it was in at the time of the earlier backup; any updates made since that point are lost. Here is a Windows batch file that performs the simple full restore for Example 1: ATTRIB -R test9.db ATTRIB -R test9.log ATTRIB -R C:\mirror\test9.mlg RENAME test9.db old_test9.db RENAME test9.log old_test9.log RENAME C:\mirror\test9.mlg old_test9.mlg COPY G:\bkup\test9.db test9.db COPY G:\bkup\test9.log test9.log COPY G:\bkup\test9.mlg C:\mirror\test9.mlg "%ASANY9%\win32\dbsrv9.exe" -o ex_1_console.txt -x tcpip test9.db Here’s how the batch file works for Example 1: n The three ATTRIB commands reset the “read-only” setting on the .db, .log, and .mlg files so they can be renamed. n The three RENAME commands follow the rule to “rename or copy any file that’s going to be overwritten.” n The three COPY commands restore the backup .db, .log, and .mlg files from the remote computer backup folder back to the current and mirror folders. Restoring the mirror log file isn’t really necessary, and the next few examples aren’t going to bother with it. n The last command starts the engine again, using the database and transac - tion log files that were just restored. The -o option specifies that the data - base console window messages should also be written to a file. Example 2: The current database is unusable but the current transaction file is still available, and the most recent backup was a full online image backup of both the database and transaction log as described earlier in this section. The 388 Chapter 9: Protecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. following statement performed the backup and created G:\bkup\test9.db and G:\bkup\test9.log: BACKUP DATABASE DIRECTORY 'G:\bkup'; In this case, the backup database file is copied back from the backup folder, and the current transaction log file is applied to the database to bring it forward to a more recent state. All the committed transactions will be recovered, but any changes that were uncommitted at the time of failure will be lost. Here is a Win - dows batch file that will perform the restore for Example 2: ATTRIB -R test9.db RENAME test9.db old_test9.db COPY test9.log old_test9.log COPY G:\bkup\test9.db test9.db "%ASANY9%\win32\dbsrv9.exe" -o ex_2_console.txt test9.db -a G:\bkup\test9.log "%ASANY9%\win32\dbsrv9.exe" -o ex_2_console.txt test9.db -a test9.log "%ASANY9%\win32\dbsrv9.exe" -o ex_2_console.txt -x tcpip test9.db Here’s how the batch file works for Example 2: n The ATTRIB command resets the “read-only” setting on the current .db file. In this example the current .log file is left alone. n The RENAME command and the first COPY follow the rule to “rename or copy any file that’s going to be overwritten”; the database file is going to be overwritten with a backup copy, and the current transaction log is eventu- ally going to be updated when the server is started in the final step. n The second COPY command restores the backup .db file from the remote computer backup folder back to the current folder. n The next command runs dbsrv9.exe with the option “-a G:\bkup\test9.log,” which applies the backup .log file to the freshly restored .db file. All the committed changes that exist in that .log file but are not contained in the database itself are applied to the database; this step is required because an online BACKUP statement performed the original backup, and the backup transaction log may be more up to date than the corresponding backup data - base file. When the database engine is run with the -a option, it operates as if it were a batch utility program and stops as soon as the roll forward pro - cess is complete. n The second-to-last command runs dbsrv9.exe with the option “-a test9.log,” which applies the current .log file to the database. This will bring the data - base up to date with respect to committed changes made after the backup. n The last command starts the engine again, using the restored .db file and current .log file. Note: In most restore procedures, the backup transaction log file that was created at the same time as the backup database file is the first log that is applied using the dbsrv9 -a option, as shown above. In this particular example that step isn’t necessary because the current transaction log contains everything that’s necessary for recovery. In other words, the dbsrv9.exe command with the option “-a G:\bkup\test9.log” could have been omitted; it does no harm, how - ever, and it is shown here because it usually is necessary. Here is some of the output that appeared in the database console window during the last three steps of Example 2: Chapter 9: Protecting 389 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. I. 03/17 09:21:27. Adaptive Server Anywhere Network Server Version 9.0.0.1270 I. 03/17 09:21:27. Starting database "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:27. Database recovery in progress I. 03/17 09:21:27. Last checkpoint at Wed Mar 17 2004 09:17 I. 03/17 09:21:27. Checkpoint log I. 03/17 09:21:27. Transaction log: G:\bkup\test9.log I. 03/17 09:21:27. Rollback log I. 03/17 09:21:27. Checkpointing I. 03/17 09:21:27. Starting checkpoint of "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:27. Finished checkpoint of "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:27. Recovery complete I. 03/17 09:21:27. Database server stopped at Wed Mar 17 2004 09:21 I. 03/17 09:21:27. Starting database "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:27. Database recovery in progress I. 03/17 09:21:27. Last checkpoint at Wed Mar 17 2004 09:21 I. 03/17 09:21:27. Checkpoint log I. 03/17 09:21:27. Transaction log: test9.log I. 03/17 09:21:27. Rollback log I. 03/17 09:21:27. Checkpointing I. 03/17 09:21:28. Starting checkpoint of "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Finished checkpoint of "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Recovery complete I. 03/17 09:21:28. Database server stopped at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Starting database "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Transaction log: test9.log I. 03/17 09:21:28. Transaction log mirror: C:\mirror\test9.mlg I. 03/17 09:21:28. Starting checkpoint of "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Finished checkpoint of "test9" at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Database "test9" (test9.db) started at Wed Mar 17 2004 09:21 I. 03/17 09:21:28. Database server started at Wed Mar 17 2004 09:21 I. 03/17 09:21:36. Now accepting requests The restore shown above recovers all the committed changes made up to the point of failure, because they were all contained in the transaction log. It is also possible to recover uncommitted changes if they are also in the transaction log, and that will be true if a COMMIT had been performed on any other connection after the uncommitted changes had been made; in other words, any COMMIT forces all changes out to the transaction log. Following is an example of how the dbtran.exe utility may be used to ana - lyze a transaction log file and produce the SQL statements corresponding to the changes recorded in the log. The -a option tells dbtran.exe to include uncommit - ted operations in the output, and the two file specifications are the input transaction log file and the output text file. "%ASANY9%\win32\dbtran.exe" -a old_test9.log old_test9.sql Here is an excerpt from the output text file produced by the dbtran.exe utility; it contains an INSERT statement that may be used in ISQL if you want to recover this uncommitted operation: INSERT-1001-0000385084 INSERT INTO DBA.t1(key_1,non_key_1) VALUES (9999,'Lost uncommitted insert') Example 3: The current database is unusable but the current transaction file is still available, and the backups consist of an earlier full online image backup 390 Chapter 9: Protecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. that renamed and restarted the transaction log, followed by two incremental log backups. Here are the statements that created the backups: BACKUP DATABASE DIRECTORY 'G:\bkup' TRANSACTION LOG RENAME MATCH; BACKUP DATABASE DIRECTORY 'G:\bkup' TRANSACTION LOG ONLY TRANSACTION LOG RENAME MATCH; BACKUP DATABASE DIRECTORY 'G:\bkup' TRANSACTION LOG ONLY TRANSACTION LOG RENAME MATCH; In this case, the backup database file must be copied back from the remote backup folder, and then a whole series of transaction logs must be applied to bring the database forward to a recent state. Here is a Windows batch file that will perform the restore for Example 3: ATTRIB -R test9.db RENAME test9.db old_test9.db COPY test9.log old_test9.log COPY G:\bkup\test9.db "%ASANY9%\win32\dbsrv9.exe" -o ex_3_console.txt test9.db -a G:\bkup\040317AA.LOG "%ASANY9%\win32\dbsrv9.exe" -o ex_3_console.txt test9.db -a G:\bkup\040317AB.LOG "%ASANY9%\win32\dbsrv9.exe" -o ex_3_console.txt test9.db -a G:\bkup\040317AC.LOG "%ASANY9%\win32\dbsrv9.exe" -o ex_3_console.txt test9.db -a test9.log "%ASANY9%\win32\dbsrv9.exe" -o ex_3_console.txt -x tcpip test9.db Here’s how the batch file works for Example 3: n The ATTRIB command resets the “read-only” setting on the current .db file. n The RENAME command and the first COPY follow the rule to “rename or copy any file that’s going to be overwritten.” Note that if everything goes smoothly, all these “old*.*” files can be deleted. n The second COPY command copies the backup .db file from the backup folder back to the current folder. n The next three commands run dbsrv9.exe with the -a option to apply the oldest three transaction log backups in consecutive order. n The second-to-last command runs dbsrv9.exe with -a to apply the current transaction log to bring the database up to date as far as committed transac - tions are concerned. n The last command starts the engine again, using the restored .db file and current .log file. Here is some of the output that appeared in the database console window during the five dbsrv9.exe steps in Example 3: I. 03/17 09:44:00. Starting database "test9" at Wed Mar 17 2004 09:44 I. 03/17 09:44:00. Transaction log: G:\bkup\040317AA.LOG I. 03/17 09:44:01. Starting database "test9" at Wed Mar 17 2004 09:44 I. 03/17 09:44:01. Transaction log: G:\bkup\040317AB.LOG I. 03/17 09:44:01. Starting database "test9" at Wed Mar 17 2004 09:44 I. 03/17 09:44:01. Transaction log: G:\bkup\040317AC.LOG Chapter 9: Protecting 391 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. I. 03/17 09:44:01. Starting database "test9" at Wed Mar 17 2004 09:44 I. 03/17 09:44:02. Transaction log: test9.log I. 03/17 09:44:02. Starting database "test9" at Wed Mar 17 2004 09:44 I. 03/17 09:44:02. Transaction log: test9.log I. 03/17 09:44:10. Now accepting requests Example 4: The main computer is unavailable, and the backups are the same as shown in Example 3, with the addition of a live log backup running on the remote computer. Here are the commands run on the remote computer to start the live log backup: SET CONNECTION="ENG=test9;DBN=test9;UID=dba;PWD=sql;LINKS=TCPIP(HOST=TSUNAMI)" "%ASANY9%\win32\dbbackup.exe" -c %CONNECTION% -l bkup\live_test9.log bkup Here are the statements run on the main computer to create the backups: BACKUP DATABASE DIRECTORY 'G:\bkup' TRANSACTION LOG RENAME MATCH; BACKUP DATABASE DIRECTORY 'G:\bkup' TRANSACTION LOG ONLY TRANSACTION LOG RENAME MATCH; BACKUP DATABASE DIRECTORY 'G:\bkup' TRANSACTION LOG ONLY TRANSACTION LOG RENAME MATCH; In this case, the restore process must occur on the remote computer. Here is a Windows batch file that will perform the restore for Example 4: COPY bkup\test9.db COPY bkup\live_test9.log test9.log "%ASANY9%\win32\dbsrv9.exe" -o ex_4_console.txt test9.db -a bkup\040317AD.LOG "%ASANY9%\win32\dbsrv9.exe" -o ex_4_console.txt test9.db -a bkup\040317AE.LOG "%ASANY9%\win32\dbsrv9.exe" -o ex_4_console.txt test9.db -a bkup\040317AF.LOG "%ASANY9%\win32\dbsrv9.exe" -o ex_4_console.txt test9.db -a test9.log "%ASANY9%\win32\dbsrv9.exe" -o ex_4_console.txt -x tcpip test9.db Here’s how the batch file works for Example 4: n The first COPY command copies the backup .db file from the backup folder to the current folder. Note that the backup folder is simply referred to as “bkup” rather than “G:\bkup” because all these commands are run on the remote computer. n The second COPY command copies the live log backup from the backup folder to the current folder, and renames it to “test9.log” because it’s going to become the current transaction log. n The next three commands run dbsrv9.exe with the -a option to apply the oldest three transaction log backups in consecutive order. n The second-to-last command runs dbsrv9.exe with -a to apply the current transaction log, formerly known as the live log backup file. This brings the database up to date as far as all the committed transactions that made it to the live log backup file are concerned. n The last command starts the engine again, using the restored .db file and current .log file. Clients can now connect to the server on the remote 392 Chapter 9: Protecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. computer; this may or may not require changes to the connection strings used by those clients, but that issue isn’t covered here. 9.14 Validation If you really want to make sure your database is protected, every backup data - base file and every backup transaction log should be checked for validity as soon as it is created. There are two ways to check the database: Run the dbvalid.exe utility pro - gram, or run a series of VALIDATE TABLE and VALIDATE INDEX statements. Both of these methods require that the database be started. Following are two Windows batch files that automate the process of run - ning dbvalid.exe. The first batch file, called copy_database_to_validate.bat, makes a temporary copy of the database file so that the original copy remains undisturbed by the changes made whenever a database is started. It then uses dblog.exe with the -n option to turn off the transaction log and mirror log files for the copied database, runs dbsrv9.exe with the -f option to force recovery of the copied database without the application of any log file, and finally starts the copied database using dbsrv9.exe: ATTRIB -R temp_%1.db COPY /Y %1.db temp_%1.db "%ASANY9%\win32\dblog.exe" -n temp_%1.db "%ASANY9%\win32\dbsrv9.exe" -o console.txt temp_%1.db -f "%ASANY9%\win32\dbsrv9.exe" -o console.txt temp_%1.db The second Windows batch file, called validate_database_copy.bat, runs dbvalid.exe on the temporary copy of the database: @ECHO OFF SET CONNECTION="ENG=temp_%1;DBN=temp_%1;UID=dba;PWD=sql" ECHO ***** DBVALID %CONNECTION% >>validate.txt DATE /T >>validate.txt TIME /T >>validate.txt "%ASANY9%\win32\dbvalid.exe" -c %CONNECTION% -f -o validate.txt IF NOT ERRORLEVEL 1 GOTO OK ECHO ON REM ***** ERROR: DATABASE IS INVALID ***** GOTO END :OK ECHO ON ECHO OK >>validate.txt Here’s how the validate_database_copy.bat file works: n The ECHO OFF command cuts down on the display output. n The SET command creates a local environment variable to hold the connec - tion string. n The ECHO, DATE, and TIME commands start adding information to the validate.txt file. n The next command runs dbvalid.exe with the -f option to perform a full check of all tables and the -o option to append the display output to the val - idate.txt file. The -c option is used to connect to a running database, which in this case is a temporary copy of the original database. n The IF command checks the return code from dbvalid.exe. A return code of zero means everything is okay, and any other value means there is a Chapter 9: Protecting 393 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. problem. The IF command can be interpreted as follows: “if not ( return code >= 1 ) then go to the OK label, else continue with the next command.” n The remaining commands display “ERROR” or “DATABASE IS OK,” depending on the return code. Here is an example of how the two batch files above are executed, first for a valid database and then for a corrupted database. Both batch files take the file name portion of the database file name as a parameter, with the .db extension omitted: copy_database_to_validate valid_test9 validate_database_copy valid_test9 copy_database_to_validate invalid_test9 validate_database_copy invalid_test9 Here’s what validate_database_copy.bat displayed for the database that was okay: Adaptive Server Anywhere Validation Utility Version 9.0.0.1270 No errors reported E:\validate>ECHO OK 1>>validate.txt E:\validate>REM ***** DATABASE IS OK ***** Here is what validate_database_copy.bat displayed for the database with a prob- lem, in particular an index that has become corrupted: Adaptive Server Anywhere Validation Utility Version 9.0.0.1270 Validating DBA.t1 Run time SQL error — Index "x1" has missing index entries 1 error reported E:\validate>REM ***** ERROR: DATABASE IS INVALID ***** Here is the contents of the validate.txt file after the above two runs of vali- date_database_copy.bat; it records the database connection parameters, date, time, and validation results: ***** DBVALID "ENG=temp_valid_test9;DBN=temp_valid_test9;UID=dba;PWD=sql" Wed 03/17/2004 8:19a Adaptive Server Anywhere Validation Utility Version 9.0.0.1270 No errors reported OK ***** DBVALID "ENG=temp_invalid_test9;DBN=temp_invalid_test9;UID=dba;PWD=sql" Wed 03/17/2004 8:19a Adaptive Server Anywhere Validation Utility Version 9.0.0.1270 Run time SQL error — Index "x1" has missing index entries 1 error reported Here is the syntax for the VALIDATE TABLE statement: <validate_table> ::= VALIDATE TABLE [ <owner_name> "." ] <table_name> [ <with_check> ] <with_check> ::= WITH DATA CHECK adds data checking | WITH EXPRESS CHECK adds data, quick index checking | WITH INDEX CHECK adds full index checking | WITH FULL CHECK adds data, full index checking In the absence of any WITH clause, the VALIDATE TABLE statement performs some basic row and index checks. The various WITH clauses extend the check - ing as follows: 394 Chapter 9: Protecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. n WITH DATA CHECK performs extra checking of blob pages. n WITH EXPRESS CHECK performs the WITH DATA checking plus some more index checking. n WITH INDEX CHECK performs the same extensive index checking as the VALIDATE INDEX statement, on every index for the table. n WITH FULL CHECK is the most thorough; it combines the WITH DATA and WITH INDEX checking. Here is an example of a VALIDATE TABLE statement that was run against the same database that had the error detected by dbvalid.exe in the previous example: VALIDATE TABLE t1; The VALIDATE TABLE statement above set the SQLSTATE to '40000' and produced the same error message: “Run time SQL error — Index "x1" has miss - ing index entries.” The VALIDATE INDEX statement checks a single index for validity; in addition to the basic checks, it confirms that every index entry actually corre - sponds to a row in the table, and if the index is on a foreign key it ensures the corresponding row in the parent table actually exists. There are two different formats for VALIDATE INDEX, one for a primary key index and one for other kinds of indexes. Here is the syntax: <validate_primary_key> ::= VALIDATE INDEX [ [ <owner_name> "." ] <table_name> "." ] <table_name> <validate_other_index> ::= VALIDATE INDEX [ [ <owner_name> "." ] <table_name> "." ] <index_name> <index_name> ::= <identifier> Here is an example of a VALIDATE INDEX statement that checks the primary key index of table t1; this index is okay so this statement sets SQLSTATE to '00000': VALIDATE INDEX DBA.t1.t1; Here is an example of a VALIDATE INDEX statement that checks an index named x1 on the table t1. When it is run against the same database as the previ - ous VALIDATE TABLE example, this statement also sets the SQLSTATE to '40000' and produces the same error message about missing index entries: VALIDATE INDEX t1.x1; Here is an example of a VALIDATE INDEX statement that checks a foreign key with a role name of fk2 on table t2: VALIDATE INDEX t2.fk2; In this case, the foreign key column value in one row of the table has been cor - rupted, and the VALIDATE INDEX produces the following error message: Run time SQL error — Foreign key "fk2" for table "t2" is invalid because primary key or unique constraint "t1" on table "t1" has missing entries A transaction log file can be checked for validity by using the dbtran.exe utility to attempt to translate the log into SQL commands. If the attempt succeeds, the log is okay; if the attempt fails, the log is not usable for recovery purposes. Chapter 9: Protecting 395 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... trigger Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 416 10.5 Chapter 10: Tuning Graphical Plan The Graphical Plan is a feature that displays the “execution plan” that SQL Anywhere chooses for a particular query, whether it is a straightforward SELECT or an INSERT, UPDATE, or DELETE involving a query The execution plan is very important to performance; SQL Anywhere usually chooses... counters that SQL Anywhere maintains, and the last section gathers together a list of tips and techniques that didn’t get covered in the preceding sections 10.2 Request-Level Logging The SQL Anywhere database engine offers a facility called request-level logging that creates a text file containing a trace of requests coming from client applications This output can be used to determine which SQL statements... output file, starts the recording process, and sets the level of detail to be recorded The choices for level of detail are 'SQL' to show SQL statements in the output file, 'SQL+ hostvars' to include host variable values together with the SQL statements, and 'ALL' to include other non -SQL traffic that comes from the clients to the server The first two settings are often used for analyzing performance, whereas... SQL Anywhere starts a database The last three sections, 9.12 through 9.14, described database backup and restore procedures and how to validate backup files to make sure they’re usable if you need to restore the database The next chapter moves from protection to performance: It presents various methods and approaches you can use to improve the performance of SQL Anywhere databases Please purchase PDF. .. can make a huge difference in the plan that ISQL displays and it’s important to get the correct information when you’re trying to improve performance You can display the Graphical Plan by pasting the query into the SQL Statements pane of ISQL and then pressing Shift+F5 or choosing the menu options SQL > Get Plan For example, here is the most time-consuming SQL statement from an earlier example in Section... a text file called validate.txt, the -y option to overwrite the output SQL file, the %1 notation to represent the batch file parameter value, and the output SQL file called dummy .sql ECHO OFF ECHO ***** DBTRAN %1 >>validate.txt DATE /T >>validate.txt TIME /T >>validate.txt "%ASANY9%\win32\dbtran.exe" -o validate.txt -y %1 dummy .sql IF NOT ERRORLEVEL 1 GOTO OK ECHO ON REM ***** ERROR: LOG IS INVALID... NULL, Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 402 Chapter 10: Tuning stmt LONG VARCHAR NOT NULL, prefix LONG VARCHAR NULL, PRIMARY KEY ( req_id ) ) ON COMMIT PRESERVE ROWS; Each row in satmp_request_time corresponds to one SQL statement The req_id column contains the first line number in the request-level logging file corresponding to that SQL statement and can be... Profiling > Start Profiling (see Figure 10-10) Figure 10-10 Starting the Execution Profiler from Sybase Central Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 414 Chapter 10: Tuning From this point forward, until you click on Profiling > Stop Profiling, SQL Anywhere will gather information about how much time is spent executing each statement inside each stored procedure and trigger... request-level logging facility or Index Consultant The section on the Graphical Plan talks about how to examine individual queries for performance problems involving SQL Anywhere s query engine Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 399 400 Chapter 10: Tuning Section 10.6 and its subsections are devoted to file, table, and index fragmentation and ways to deal with... and facilities that are used to protect the integrity of SQL Anywhere databases Section 9.2 discussed local and global database options and how values can exist at four different levels: internal default values, public defaults, user defaults, and the values currently in use on a particular connection Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 9: Protecting 397 . purchase PDF Split-Merge on www.verypdf.com to remove this watermark. SET CONNECTION="ENG=test9;DBN=test9;UID=dba;PWD =sql& quot; "%ASANY9%win32dbisql.exe". for perfor - mance problems involving SQL Anywhere s query engine. 399 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Section