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.
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
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.
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.
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
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:
To start QSA on a remote Windows server
Start the Quest Server Agent using one of the following methods:
To start QSA on a UNIX or Linux server
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:
To stop QSA on a remote Windows server
Stop the Quest Server Agent using one of the following methods:
To stop QSA on a UNIX or Linux server
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:
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
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.
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
Run the manual configuration script using the following command and cases:
# ./QSAConfig
From the Quest Server Agent Parameters window, modify values for the agent parameters as needed:
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:
QSA Server Agent Locking Strategies
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:
|
| 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 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).
| 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.
The following parameters are used to configure Simple Network Management Protocol (SNMP) Trap notifications.
| 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). |
After enabling SMTP email or SNMP trap notification methods, you can specify additional notification events by configuring the following parameters.
| 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. |
Use the following parameters to specify the type of results report to include when using the SEND_LR_COMPLETE parameter.
| 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. |
Use the following parameters to configure advanced options for locks reporting.
| 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 | |
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.
To set locks reporting parameters
Start Space Manager and connect to the target database for the Quest Server Agent.
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.
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.
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 | |
© ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center
