This section provides additional information and guidelines to follow when installing QSA in an OPS or RAC environment that uses an active-active configuration.
Note: The Server Agent does not failover from one instance to another in an active-active environment. If the agent instance fails during script execution by the agent, execution aborts. To resolve this problem, bring up the instance where the agent is installed and restart script execution. If you cannot bring up the agent instance, contact Quest Software Support for assistance.
QSA should be installed on only one instance in an active-active OPS or RAC environment. The instance should be the primary instance.
To ensure that you connect to the correct instance, create a connection for that instance before you install the agent. See the following section, “Connection Setup for OPS or RAC.”
When the connection is available, the connection information is automatically passed to the QSA Installer when you run it to install or upgrade QSA. This also happens when you connect to the agent instance from Space Manager and use Tools | Admin | Quest Server Agent | Manage Quest Server Agent to start the QSA Installer. If a connection is not available, Oracle randomly connects to an instance.
Note: Upgrade QSA on the instance where it is currently installed. If you want to upgrade the agent on a different instance, first uninstall the agent from its current instance.
To create a connection to the instance for QSA, you must configure the TNSNAMES.ORA file, the Oracle Names server, or the directory service. You configure it with information such as the service name and instance name for the agent instance.
To configure the TNSNAMES.ORA file with connection information for the agent instance, include an entry for this instance in the file. The CONNECT_DATA descriptor should contain the service name and instance name for the instance. SID is not needed.
Use the following example as a model:
(ADDRESS = (PROTOCOL = TCP) (HOST = srv01) (PORT = 1521))
(SERVICE_NAME = rac1)
(INSTANCE_NAME = rac11)
If an error occurs during an upgrade of QSA in an active-active OPS or RAC environment, either a host or an instance message may display.
A host message displays if you are not connected to the database server host where the agent is currently installed. The message prompts you to manually uninstall the older version of the agent.
Perform one of the following actions:
An instance message displays if you are not connected to the instance where the agent is currently installed. The message prompts you to connect to the agent instance. The message typically displays if you have not performed connection setup. In this case, Oracle randomly connects the QSA Installer to an instance that is not the agent instance.
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.
The following table contains a list of Quest Server Agent parameters and descriptions.
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 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.|
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 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).
|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.|
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.
|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.
|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 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.
Select YES to enable locks reporting.
Note: When you disable locks reporting, the values selected for the other parameters have no effect.
Select YES to enable reporting of locks for canceled jobs.
Note: Space Manager reports locks held by Oracle sessions for canceled jobs to the qexecd.log file before canceling the job.
Select YES to enable reporting of locks when a table lock or a T-Lock fails with a resource busy error (ORA-0054).
Note: Space Manager reports these locks to the script execution log that you can view using the Script/Job Monitor.
Select YES to enable reporting of locks to a system file.
Select YES to append the system file created for locks reporting.
Note: If you disable this parameter, the system file only contains information for the most recent lock reported.
Enter a value for the number of times to report locks for a specific table.
Range: 1 to 999
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
This chapter describes how to uninstall Space Manager and QSA.
To uninstall Space Manager, you remove server components and QSA from each database in which they are installed. You also remove the Space Manager client and demonstration data, if installed.
The main steps in the uninstall process are as follows:
Note: Make sure that no scripts are running or scheduled to run when uninstalling the server components and the Server Agent.