Space Manager with LiveReorg 9.1

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:

When statement-level restart is used, execution resumes from the statement on which it was interrupted.
When section-level restart is used, execution resumes from the last “restart point” reached when execution was interrupted. A restart point marks the beginning of each restart section in a script. A restart section consists of a sequence of statements that must be executed when a script is restarted. As a script is executed, QSA keeps track of its progress through restart points.

For both types of restart, restart is initiated with the ALWAYS_RUN command.

Restart for Standard Reorganization Scripts

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 Commands

This section describes the commands used for script restart. Like LiveReorg commands, all begin with QUEST_EXEC.

ALWAYS_RUN_BEGIN and ALWAYS_RUN_END

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).

RESTART_POINT

The RESTART_POINT command tells QSA to perform a section-level restart:

In live and partitioning scripts, a RESTART_POINT command precedes the LW_START_REORG command for each table. If execution is interrupted before a copy table is created for an original table, execution is restarted from the table’s RESTART_POINT command. If execution is interrupted after a copy table is created, execution is restarted from the point at which it failed.

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);

STATEMENT_LEVEL_RESTART

The STATEMENT_LEVEL_RESTART command tells QSA to use a statement-level restart:

In standard scripts, there is one STATEMENT_LEVEL_RESTART command per script. It applies to all tables. The command occurs at the beginning of the script. When a statement level restart is performed for a standard reorganization script, execution is restarted from the statement on which it was interrupted.

Monitor Scripts

How to Monitor 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:

In the Job Monitor
Using the Script Properties dialog
In the SQL Editor
Using email notifications
Using Live Reorg Shell

Job Monitor vs Properties Dialog

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:

View script status
View script execution schedule, as well as execution start and stop times
View each script statement as it is processed (for currently-executing scripts)

How do the windows differ?

Job Monitor—The Job Monitor provides a list of all stored scripts for a database.
- Use this window to view the status, script type, start and stop times, and status code for all scripts.
- If a script fails, the error code is displayed for the individual script that failed.
- This window allows you to drill down to view the status of each individual script in a group.
- View script logs for individual script executions.
- Open a script in the Editor window.
See Using Job Monitor to Monitor Scripts for more information.
Group Properties—The Group Properties dialog allows you to perform tasks on a script group, for example:
- View or modify the execution schedule
- Change the approval method for the switch
See Using Group and Script Properties to Monitor Scripts for more information.
Script Properties—The Script Properties dialog allows you to focus on individual stored scripts.
- Use this dialog to monitor the execution progress of an individual script.
- View the number of errors and warnings that occur during script execution
- View total number of statements in a script
- View the number of statements successfully executed so far
- View complete script statements for an executing script
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.

Monitor Interactive Execution in Editor

You can monitor interactive execution of reorganization scripts from the SQL Editor. See Run Scripts from the Editor for more information.

Use Email to Monitor Script Status and Results

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.

To enable email notifications, see Enable Email (SMTP) Notification.
To enable SNMP trap notifications, see Enable SNMP Traps Notification.

After enabling the email or SNMP trap notification feature, you can configure additional notification events. See Configure Additional Notification Events for more information.

Use Live Reorg Shell

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.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.