Restart for standard reorganization scripts is managed mainly with restart commands. These commands provide two types of restart—statement-level restart and section-level restart:
For both types of restart, restart is initiated with the ALWAYS_RUN command.
In most cases, a statement-level restart is used for standard reorganization scripts. Execution resumes from the statement on which it was interrupted. However, if execution stopped inside a parallel block, a section-level restart is used. In this case, execution resumes from the restart point that precedes the parallel block.
Restart for Live and Partitioning Scripts
This section describes the commands used for script restart. Like LiveReorg commands, all begin with QUEST_EXEC.
The ALWAYS_RUN_BEGIN command marks the start of the “always run” section of a script. The ALWAYS_RUN_END command marks the end of this section.
The “always run” section is always run first when a script is restarted. It includes
a connection string and any session parameters set from Space Manager. It can
also include the ALTER_USER_QUOTA statement and the CHECK_ENGINE statement. (The latter is contained in live reorganization scripts, partitioning scripts, and scripts that use FastCopy or parallel QSA processes).
The RESTART_POINT command tells QSA to perform a section-level restart:
The RESTART_POINT command for each table in a script is assigned a sequential number. This is displayed in parentheses beside the command. It associates a table with its parallel blocks (used for tasks performed in parallel). The following is an example of the command and sequential number for the second table in a script:
EXECUTE QUEST_EXEC.RESTART_POINT('2');
The same number is displayed in the BEGIN_PARALLEL command for each of a table’s parallel blocks. Number of parallel QSA processes is displayed beside the sequential number. The following is an example of the BEGIN_PARALLEL, sequential number, and number of parallel processes for the second table in a script:
EXECUTE QUEST_EXEC.BEGIN_PARALLEL('2', 3);
The STATEMENT_LEVEL_RESTART command tells QSA to use a statement-level restart:
Restart for Live and Partitioning Scripts
After you schedule and store a script, you can monitor script execution using the Job Monitor and other dialogs and tools. Space Manager provides the following methods to monitor scripts:
Both windows display the status of the scripts that are stored in the Space Manager repository for execution by QSA. You can use both the Job Monitor and the Properties dialog to do the following monitoring tasks:
See Using Job Monitor to Monitor Scripts for more information.
See Using Group and Script Properties to Monitor Scripts for more information.
See Using Group and Script Properties to Monitor Scripts for more information.
Information on a script is available in both windows as soon as the script is stored in the repository. This is the case even if scripts are not scheduled when they are stored.
You can monitor interactive execution of reorganization scripts from the SQL Editor. See Run Scripts from the Editor for more information.
You can configure Quest Service Agent (QSA) to send notifications/alerts via email to help you monitor the progress of script execution. QSA can be configured to automatically send email notifications at almost any step in the reorganization process or if the script execution fails. You can also configure QSA to send an email containing the reorganization results.
Notifications can be sent in two ways: email (SMTP) or SNMP trap. To enable one or both of these methods, you must first define the parameters in QSA.
After enabling the email or SNMP trap notification feature, you can configure additional notification events. See Configure Additional Notification Events for more information.
Live Reorg Shell (LRSH) is a command line tool you can use to monitor Live Reorg scripts when you do not have access to the Space Manager desktop application. See Monitor Scripts Using Live Reorg Shell for more information.
© ALL RIGHTS RESERVED. 이용 약관 개인정보 보호정책 Cookie Preference Center