Converse agora com nosso suporte
Chat com o suporte

Space Manager with LiveReorg 9.1 - User Guide

Smart Start for Space Manager Collect Statistics Profile DML Activity Manage Storage Reorganize Objects with Reorg Manager Partition Tables with the Partitioning Wizard Run and Monitor Scripts Run Reports Options Troubleshooting Administration Functions Appendix About Us

Start/Stop Server Agent

You can start or stop the Quest Server Agent (QSA) using administration functions from the Tools | Admin | Quest Server Agent menu.

Note: If you are running Space Manager in an active-active OPS or RAC environment, you must connect to the instance where the Quest Server Agent is installed before you can start or stop the agent.

Tip: You can also start or stop the Quest Server Agent from the Scripts/Job Monitor window. See Manage and Monitor QSA for more information.

Start QSA Using the Admin Function

The Start Quest Server Agent function can be used, if necessary, to start the Quest Server Agent. In most cases, the agent starts automatically when it is installed. It then runs continuously, waiting to execute scripts at their scheduled times. Normally, the agent only needs to be restarted after it is stopped using the Stop Quest Server Agent function. When the agent is stopped, Not running is displayed in the Quest Server Agent Status panel in the Scripts/Job Monitor window.

The Start Quest Server Agent function can be used to start the agent on local Windows servers (those that reside on your Space Manager client computer) and on UNIX and Linux servers to which you have both SSH and SFTP access. To start QSA with other configurations, see the section "Start QSA Under Special Circumstances" in this topic.

To start QSA using the admin function

  1. Select Tools | Admin | Quest Server Agent | Start Quest Server Agent.
  2. If you are starting the agent on a UNIX or Linux server, the server login dialog displays. Enter the login name and password for the UNIX or Linux account that is being used to run the agent.
  3. When the Quest Server Agent Started message displays, click OK to clear it.
  4. Check the status of the agent from the Scripts/Job Monitor. Running is displayed in the Quest Server Agent Status panel when the agent is started.

Note: If QSA is not running when a script’s scheduled execution time occurs, you have 10 minutes in which to start it. The script is executed when QSA starts. If QSA starts after the 10-minute time window ends, the script aborts with this error: “QSA-20312: Scheduled launch time expired”. To run a script whose launch time has expired, execute it on demand or reschedule it from the Scripts/Job Monitor.

Restart QSA Using the Admin Function

Use the Restart Quest Server Agent function when you do not have the permission level necessary to start the Quest Server Agent. The Restart Quest Server Agent function automatically stops and restarts the agent. This only requires the same permission level as that for stopping the agent.

To restart QSA using the admin function

» Select Tools | Admin | Quest Server Agent | Restart Quest Server Agent.

After the agent restarts, a Quest Server Agent restarted message displays.

Stop QSA Using the Admin Function

The Stop Quest Server Agent function can be used, if necessary, to stop the Quest Server Agent. The agent should not be stopped when scheduled scripts are executing or are scheduled to execute.

The Stop Quest Server Agent function can be used to stop the agent on local Windows servers (those that reside on your Space Manager client computer) and on UNIX and Linux servers to which you have both SSH and SFTP access. To stop QSA with other configurations, see the section "Stop QSA Under Special Circumstances" in this topic.

To stop QSA using the admin function

  1. Select Tools | Admin | Quest Server Agent | Stop Quest Server Agent.
  2. When the Quest Server Agent Stopped message displays, click OK to clear it.
  3. Check the status of the agent from the Scripts/Job Monitor. Not running is displayed in the Quest Server Agent Status panel when the agent is stopped.

Start QSA Under Special Circumstances

In most cases, you can start the Quest Server Agent using client administrative functions. However, you need to use one of the following procedures if the agent is installed on:

  • A remote Windows server. This is a server that does not reside on your Space Manager client computer.
  • A UNIX or Linux server to which the Space Manager client computer does not have both SSH and SFTP access.

To start QSA on a remote Windows server

  1. Log in to the server as a member of the Windows Administrators Group.
  2. Start the Quest Server Agent using one of the following methods:

    • From the Windows Services window, right-click Quest Server Agent and select Start.
    • From the \bin subdirectory of the agent install directory, run this command: QSAStart.cmd

To start QSA on a UNIX or Linux server

  1. Log in to the server under the UNIX or Linux account that is being used to run the agent.
  2. From the \bin subdirectory of the agent install directory, run this script: QSAStart.sh

Stop QSA Under Special Circumstances

In most cases, you can stop the Quest Server Agent using client administrative functions. However, you need to use one of the following procedures if the agent is installed on:

  • A remote Windows server. This is a server that does not reside on your Space Manager client computer.
  • A UNIX or Linux server to which the Space Manager client computer does not have both SSH and SFTP access.

To stop QSA on a remote Windows server

  1. Log in to the server as a member of the Windows Administrators Group.
  2. Stop the Quest Server Agent using one of the following methods:

    • From the Windows Services window, right-click Quest Server Agent and select Stop.
    • From the \bin subdirectory of the agent install directory on the server, run this command: QSAStop.cmd

To stop QSA on a UNIX or Linux server

  1. Log in to the server under the UNIX or Linux account that is being used to run the agent.
  2. From the \bin subdirectory of the agent install directory, run this script: QSAStop.sh

  

Specify Server Agent Parameters

Parameters for the Quest Server Agent can be specified when the agent is installed or upgraded for a database. They can also be modified, when necessary, using the following procedures. In most cases, parameters can be specified using the QSA Installer (through the Space Manager client). However, they must be specified manually for databases on UNIX or Linux servers to which the Space Manager client computer does not have both SSH and SFTP access.

You can use QSA parameters to control the following activities:

  • To determine how long execution logs and script histories are kept for Space Manager scripts.
  • To control various aspects of live reorganizations and reorganizations with FastCopy.
  • To configure QSA to send email notifications about script progress or script results. See Enable Email (SMTP) Notification for more information.

Note: To specify parameters, you must log in using the same account that installed the Quest Server Agent.

To specify parameters using the QSA Installer

  1. Run Space Manager and connect to the target database for the Quest Server Agent. Connect as the Oracle DBA that installed the agent.
  2. Select Tools | Admin | Quest Server Agent | Manage Quest Server Agent Installation.
  3. Select Configure Quest Server Agent and click Next .
  4. If you are specifying the parameters on a UNIX or Linux server, the server login dialog displays. Enter the login name and password of the operating-system account that installed the agent.

    Important: If the login window does not display the name that must be used to connect to the database server host, enter the correct name in the Host Name field.

  5. In the QSA Parameters window, modify values for agent parameters as needed. See QSA Server Agent Parameters for more information.
  6. Click Next and then Finish to save your changes and close the QSA Installer.

Note: For detailed descriptions of the Quest Server Agent parameters, see the Space Manager with LiveReorg Installation Guide.

To specify parameters manually on UNIX or Linux

  1. Log in to the server under the UNIX or Linux account that installed the agent.
  2. Change to the inst subdirectory of the Quest Server Agent installation directory using the following command: # cd/$ORACLE_HOME/Quest/QSA/$ORACLE_SID/inst
  3. Run the manual configuration script using the following command and cases:

    # ./QSAConfig

  4. From the Quest Server Agent Parameters window, modify values for the agent parameters as needed:

    • At the Do you wish to modify any of these parameters prompt, enter Y (for Yes).
    • At the Please enter the ID number of the parameter prompt, enter the ID number of the parameter you want to change.
    • At each parameter prompt that displays, enter a new value for the parameter. Repeat for each parameter value you want to change.
    • When you finish entering parameters, enter N (for No) at the Do you wish to modify any of these parameters prompt.
    • At the Do you wish to save the parameter changes you’ve made prompt, enter Y (for Yes) to save all new values (enter N to revert to previous values). The Parameters Updated message is displayed.

Note: By modifying certain QSA parameters, you can enable and configure automatic email notifications to monitor script execution progress. See the following for more information:

 

  

Related Topics  

QSA Server Agent Locking Strategies

Server Agent Parameters

This section describes QSA parameters. All parameters except LW_TABLESPACE and WORKDIR have default values. The user must specify LW_TABLESPACE and WORKDIR parameters. You can change default values as needed.

To learn how to modify QSA parameters, see Specify Parameters for the QSA Server Agent.

The following table contains a list of Quest Server Agent parameters and descriptions.

Parameter Description
LW_TABLESPACE

LW_TABLESPACE specifies the tablespace for objects created by QSA during a live reorganization. One set of LiveReorg objects is created for each table in a live reorganization script. The objects are automatically dropped after a table is reorganized.

LW_TABLESPACE must have a standard name and a datafile that is at least 50 MB in size. The datafile must have at least 20 MB of contiguous free space.

Note: A tablespace must be selected for the LW_TABLESPACE parameter even if LiveReorg is not licensed.

WORKDIR

WORKDIR specifies the main directory that FastCopy (or DBMS_DataPump) should use for the data exported to the file system during a reorganization. If QSA is installed on a remote Windows server (separate from the Space Manager client computer), specify this directory as if it were on a local drive, for example, C:\TEMP. Enter the directory and path in ASCII characters.

You can use the OVERFLOW_DIR_nn parameter to specify additional directories. See the description below.

COMMIT_SIZE COMMIT_SIZE determines the amount of data FastCopy or FSCopy imports from the file system into the database before a COMMIT is performed. The parameter value can range from 1 MB to 1024 MB. The default is 10 MB.
COUNT_STAR

This parameter determines whether Quest Server Agent (QSA) performs a select count(*) on the orig_table and compares this to the number of rows copied. Select one of the following to indicate whether you want the agent to perform this extra check.

Select 1 to perform the check. This is the default.

Select 0 to NOT perform the check.

DISKSPACE_RESERVE DISKSPACE_RESERVE determines how much space is reserved for applications in WORKDIR and OVERFLOW directories. Unreserved space can be used by FastCopy/DBMS_DataPump or FSCopy for data exported during a reorganization. Once FastCopy/DBMS_DataPump or FSCopy uses all unreserved space in the WORKDIR directory, it uses unreserved space in the first OVERFLOW directory. The parameter value can range from 1 MB to 1024 MB. The default is 10 MB.
EXPORT_BUFFER_SIZE EXPORT_BUFFER_SIZE determines the maximum size of the export buffer used by FastCopy or FSCopy. Reorganizations are faster when export buffer size is at least the size of the largest row being reorganized. The parameter value can range from 32 KB to 1024 MB. The default is 1 MB.
IMPORT_METHOD

IMPORT_METHOD determines how FastCopy or FSCopy imports data from the file system into the database. There are three options:

  • AUTO—FastCopy or FSCopy uses several factors (unsupported data types, rows larger than 64 KB, and SQL*Loader errors) to determine whether to use the direct or conventional import method. FastCopy or FSCopy tries the direct method first. If unsuccessful, it automatically switches to the conventional method.
  • DIRECT—FastCopy or FSCopy uses SQL*Loader’s direct path load. The direct method is faster than the conventional because it uses the direct path API to move data and bypasses SQL processing. FastCopy or FSCopy aborts the reorganization, however, if it encounters an unsupported datatype, a row larger than 64 KB, or a SQL*Loader error.
  • CONVENTIONAL—FastCopy or FSCopy uses OCI array inserts to move data. Although slower than the direct method, the conventional method has fewer limitations and associated problems. This is the default.
IMPORT_BUFFER_SIZE IMPORT_BUFFER_SIZE determines the maximum size of the import buffer that FastCopy or FSCopy uses during imports with the conventional method. The parameter value can range from 1 MB to 1024 MB. The default is 10 MB.
LW_NULL_COLUMNS This parameter determines the maximum number of columns to check for a NULL value. The default is 32 and should not be changed.
MAX_FILE_SIZE MAX_FILE_SIZE determines the maximum size of FastCopy or FSCopy export files, which are used for the data exported from the database to the file system. (FastCopy files are in a proprietary format.) When the first file reaches the maximum size, a second file is created automatically, and so on. The parameter value can range from 1 MB to 1024 MB. (It must be less than your system’s default maximum file size.) The default is 100 MB.
MAX_HISTORY_AGE MAX_HISTORY_AGE determines the maximum number of days that records are kept in the QUEST_SCRIPT_HISTORY table. The table contains a history of script execution by QSA and is used to associate script logs with their scripts. The parameter value can range from 0 to 32765. (It should be greater than the value for MAX_LOG_AGE.) The default is 365.
MAX_LOG_AGE MAX_LOG_AGE determines the maximum number of days that script execution logs and QSA log are kept. Script logs can be used to troubleshoot script execution by the agent. The agent log (QEXECD.LOG) can be used to troubleshoot all agent activity. You can view logs from Space Manager’s Script/Job Monitor. You can send them to Quest Software Support . The parameter value can range from 0 to 365. (0 retains logs until Space Manager is uninstalled.) The default is 30.
MULTIBLOCK_READ_COUNT MULTIBLOCK_READ_COUNT determines the number of data blocks that Oracle reads at one time during a FastCopy reorganization. The number should be a multiple of the size of your operating system read buffer divided by your database block size. For example, if your operating system read buffer is 256 KB and your database block size is 8 KB, set the parameter to a multiple of 32 KB. The parameter value must be greater than or equal to 0. The default is 100.
OVERFLOW_DIR_01 thru DIR_05

OVERFLOW_DIR specifies directories that can be used in addition to the WORKDIR directory for the data FastCopy/DBMS_DataPump exports. FastCopy/DBMS_DataPump uses overflow directories when WORKDIR is full. You can specify up to 5 directories. A new directory is used when the last one used is full. Directory and path names must be entered in ASCII characters.

Note: Each overflow directory must be on a different disk. The WORKDIR disk must not be used for an OVERFLOW_DIR.

SENDMAIL Parameters

SENDMAIL parameters allow you to configure QSA to automatically send email notifications when scheduled script execution fails. Notifications identify the failure reason, script name, execution start and stop times, database server hostname, and database Oracle SID. The subject field displays “Script Failure Notice!”

SENDMAIL includes the following parameters (all except SENDMAIL_TO1 require values). See Enable Email (SMTP) Notification for more information.

QSA Parameter Description
SENDMAIL_DOMAIN Specifies the domain name of the mail server or relay server. For example: yourcompany.com.
SENDMAIL_HOST Specifies the address or fully-qualified name of the mail server or relay server host, for example: www.quest.com.
SENDMAIL_PORT Specifies the port number on which the mail server or relay server is listening.
SENDMAIL_FROM Specifies who sent the email notification. The text string you enter should be the email address of an individual or group, such as Administrator@yourcompany.com.
SENDMAIL_TO Specifies the email recipient. Must be the email address of an individual or group, such as DBA@yourcompany.com. The address must be valid. Only one address may be entered.
SENDMAIL_TO1

Specifies a second recipient for email notifications.

To specify three or more recipients, insert a row for each recipient in the QUEST_EXEC_PARAMETER table, where NAME is SENDMAIL_TO# and VALUE is a valid email address. Each SENDMAIL_TO# entry should increment by 1; for example, SENDMAIL_TO3, SENDMAIL_TO4. If there is a break in the number sequence, emails are not sent to recipients after the break. If you delete a recipient row, update the NAME rows that follow so the number sequence is preserved. You can specify a maximum of 99 recipients.

Note: For QSA to send email, Oracle’s UTL_SMTP package must be installed on the database server. The package must have access to an SMTP mail server or relay server.

SNMP Trap Parameters

The following parameters are used to configure Simple Network Management Protocol (SNMP) Trap notifications. See Enable SNMP Traps Notification for more information.

QSA Parameter Description
SNMP_TO_HOST Enter the host name for the SNMP monitor.
SNMP_PORT Enter the port number that the SNMP monitor is listening on.
SNMP_COMMUNITY Enter the name of your SNMP community (or any unique string value).

Additional Notification Parameters

After enabling SMTP email or SNMP trap notification methods, you can specify additional notification events by configuring the following parameters. See Configure Additional Notification Events for more information.

Parameter Description
SEND_GROUP_STATUS Send notification of a static change to the group status.
SEND_SCRIPT_START Send notification when script starts (101).
SEND_SCRIPT_RESTART Send notification when script is restarted (104).
SEND_SCRIPT_UNSCHEDULED Send notification when script is unscheduled (110).
SEND_SCRIPT_COMPLETE Send notification when script completes (210).
SEND_SCRIPT_CANCELLED Send notification when script is cancelled (310).
SEND_SCRIPT_ABORT Send notification when script aborts (320).
SEND_SCRIPT_HALTED Send notification when script is halted (370).
SEND_SCRIPT_SCHEDULED Send notification when a script is scheduled (410).
SEND_LR_WAIT_WINDOW Send notification when a LiveReorg is waiting for window (620).
SEND_LR_IN_WINDOW Send notification when a LiveReorg is in the window (621).
SEND_LR_WAIT_APPROVAL Send notification when a LiveReorg is waiting for approval (630).
SEND_LR_APPROVED Send notification when a LiveReorg is approved (631).
SEND_LR_START Send notification when a LiveReorg starts (710).
SEND_LR_RESTART Send notification when a LiveReorg restarts (715).
SEND_LR_COPY_START Send notification when a LiveReorg table copy starts (720).
SEND_LR_COPY_COMPLETE Send notification when a LiveReorg table copy completes (730).
SEND_LR_SWITCH_START Send notification when a LiveReorg starts to switch (740).
SEND_LR_SWITCH_COMPLETE Send notification when a LiveReorg switch completes (750).
SEND_LR_COMPLETE

Send notification when a LiveReorg completes (760).

Setting this parameter sends an email without a results report. To include a results report, use one of the SEND_LR_COMPLETE parameters listed below.

SEND_LR_COMPLETE Options

Use the following parameters to specify the type of results report to include when using the SEND_LR_COMPLETE parameter. See Configure Additional Notification Events for more information.

Parameter Results Report Type Description
SEND_LR_COMPLETE No report No report
SEND_LR_COMPLETE_DATA Detail objects, summary by object type and total savings reports. This report is the most detailed and includes the object details, detailed storage data, and a storage data summary by object.
SEND_LR_COMPLETE_SUM Summary by object type and total savings reports. This report delivers a summary of the storage data by object.
SEND_LR_COMPLETE_TOTAL Total savings report. This report lists the storage data totals only.

Locks Reporting Parameters

Use the following parameters to configure advanced options for locks reporting. See QSA Server Agent Locks Reporting Parameters for more information.

Parameter Description
LOCKS_REPORTING

Select YES to enable locks reporting.

Default: NO

Note: When you disable locks reporting, the values selected for the other parameters have no effect.

LOCKS_CANCELED_JOBS

Select YES to enable reporting of locks for canceled jobs.

Default: YES

Note: Space Manager reports locks held by Oracle sessions for canceled jobs to the qexecd.log file before canceling the job.

LOCKS_SCRIPT_LOG

Select YES to enable reporting of locks when a table lock or a T-Lock fails with a resource busy error (ORA-0054).

Default: YES

Note: Space Manager reports these locks to the script execution log that you can view using the Script/Job Monitor.

LOCKS_SYSTEM_FILE_LOGS

Select YES to enable reporting of locks to a system file.

Default: NO

LOCKS_SYSTEM_FILE_APPEND

Select YES to append the system file created for locks reporting.

Default: YES

Note: If you disable this parameter, the system file only contains information for the most recent lock reported.

LOCKS_MAXIMUM_REPORTS

Enter a value for the number of times to report locks for a specific table.

Range: 1 to 999

Default: 3

Tip: A single lock may be retired thousands of times during a single reorganization. Use the default value to minimize changes to the system file.

Note: Space Manager creates system files in the QSA log file directory with the following naming convention: <owner>.<folder>.<script>.<jobnumber>.lok

 

  

Server Agent Locks Reporting Parameters

You can use parameters for the Quest Server Agent (QSA) to configure advanced options for locks reporting. Space Manager uses locks reporting when an Oracle database has sessions holding locks that prevent LiveReorgs from starting, syncing, or switching. Held locks occur from table locks, row inserts, deletes, or updates. When you enable locks reporting, Space Manager reports Oracle session information for sessions with locks. The majority of the session information reported comes from the Oracle View v$lock file. You can configure the locks reporting parameters to report locks for a specific table when a triggering event occurs. The values chosen in the QUEST_EXEC_PARAMETER table determine how QSA reports locks.

Notes:

  • Parameters must be set by the account that installed the Quest Server Agent.

  • This topic focuses on information that may be unfamiliar to you. It does not include all step and field descriptions.

To set locks reporting parameters

  1. Start Space Manager and connect to the target database for the Quest Server Agent.

  2. Select Tools | Admin | Quest Server Agent | Manage Quest Server Agent Installation.

    Note: You can also set parameters manually. See Specify Parameters for the QSA Server Agent for more information.

  3. In the Quest Server Agent dialog, select Configure Quest Server Agent and click Next.
  4. If you are configuring parameters on a Unix or Linux server, a log-in window displays. Complete the log-on information and click Next.

    Note: To configure parameters, you must use the user login and password of the operating system account that installed the agent.

  5. Configure the parameters for locks reporting. Review the following for additional information:

    Parameter Description
    LOCKS_REPORTING

    Select YES to enable locks reporting.

    Default: NO

    Note: When you disable locks reporting, the values selected for the other parameters have no effect.

    LOCKS_CANCELED_JOBS

    Select YES to enable reporting of locks for canceled jobs.

    Default: YES

    Note: Space Manager reports locks held by Oracle sessions for canceled jobs to the qexecd.log file before canceling the job.

    LOCKS_SCRIPT_LOG

    Select YES to enable reporting of locks when a table lock or a T-Lock fails with a resource busy error (ORA-0054).

    Default: YES

    Note: Space Manager reports these locks to the script execution log that you can view using the Script/Job Monitor.

    LOCKS_SYSTEM_FILE_LOGS

    Select YES to enable reporting of locks to a system file.

    Default: NO

    LOCKS_SYSTEM_FILE_APPEND

    Select YES to append the system file created for locks reporting.

    Default: YES

    Note: If you disable this parameter, the system file only contains information for the most recent lock reported.

    LOCKS_MAXIMUM_REPORTS

    Enter a value for the number of times to report locks for a specific table.

    Range: 1 to 999

    Default: 3

    Tip: A single lock may be retired thousands of times during a single reorganization. Use the default value to minimize changes to the system file.

    Note: Space Manager creates system files in the QSA log file directory with the following naming convention: <owner>.<folder>.<script>.<jobnumber>.lok

    

Related Topics

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação