CA Workload Automation Agent for Microsoft SQL Server

Transcription

1 CA Workload Automation Agent for Microsoft SQL Server Implementation Guide r11.3.1

2 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is for your informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be disclosed by you or used for any purpose other than as may be permitted in (i) a separate agreement between you and CA governing your use of the CA software to which the Documentation relates; or (ii) a separate confidentiality agreement between you and CA. Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION AS IS WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice. The manufacturer of this Documentation is CA. Provided with Restricted Rights. Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections , , and (c)(1) - (2) and DFARS Section (b)(3), as applicable, or their successors. Copyright 2013 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

3 CA Technologies Product References This document references the following CA Technologies products: CA Process Automation CA Workload Automation AE CA Workload Automation Agent for Application Services (CA WA Agent for Application Services) CA Workload Automation Agent for Databases (CA WA Agent for Databases) CA Workload Automation Agent for i5/os (CA WA Agent for i5/os) CA Workload Automation Agent for Linux (CA WA Agent for Linux) CA Workload Automation Agent for Micro Focus (CA WA Agent for Micro Focus) CA Workload Automation Agent for Microsoft SQL Server (CA WA Agent for Microsoft SQL Server) CA Workload Automation Agent for Oracle E-Business Suite (CA WA Agent for Oracle E-Business Suite) CA Workload Automation Agent for PeopleSoft (CA WA Agent for PeopleSoft) CA Workload Automation Agent for Remote Execution (CA WA Agent for Remote Execution) CA Workload Automation Agent for SAP (CA WA Agent for SAP) CA Workload Automation Agent for UNIX (CA WA Agent for UNIX) CA Workload Automation Agent for Web Services (CA WA Agent for Web Services) CA Workload Automation Agent for Windows (CA WA Agent for Windows) CA Workload Automation CA 7 Edition CA Workload Automation DE CA Workload Automation Desktop Client (CA WA Desktop Client) CA Workload Automation ESP Edition CA Workload Control Center

4 Contact CA Technologies Contact CA Support For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA Technologies products. At you can access the following resources: Online and telephone contact information for technical assistance and customer services Information about user communities and forums Product and documentation downloads CA Support policies and guidelines Other helpful resources appropriate for your product Providing Feedback About Product Documentation If you have comments or questions about CA Technologies product documentation, you can send a message to techpubs@ca.com. To provide feedback about CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at

5 Contents Chapter 1: Introduction 7 Intended Audience... 7 Agents and Agent Plug-ins... 7 CA WA Agent for Microsoft SQL Server... 9 Supported Number of SQL Server Instances... 9 Job Types Supported by CA WA Agent for Microsoft SQL Server Properties Files Chapter 2: Implementation Checklist 11 How to Install and Configure CA WA Agent for Microsoft SQL Server Deciding Whether to Create an Alias Chapter 3: Installing the Agent Plug-in 13 CA WA Agent for Microsoft SQL Server Installation Options Controlling the Agent Plug-in Install the Agent Plug-in Using an Interactive Program Download the jtds JDBC Driver Configuring the System Properties File Available Fields in Spool File Output by Operation Configuring the Target Server Database Properties File How to Remove the Agent Plug-in Disable CA WA Agent for Microsoft SQL Server Remove the Agent Plug-in from the Scheduling Manager Chapter 4: Your Scheduling Manager and the Agent Plug-in 33 Configuring the Scheduling Manager to Work with the Agent Plug-in Running a Verification Test Chapter 5: Configuring the Agent Plug-in 35 How to Configure Agent Parameters Configure Agent Parameters on the Agent Configure Agent Parameters on the Scheduling Manager CA WA Agent for Microsoft SQL Server Parameters in the agentparm.txt File How to Set Up an Alias for the Agent Plug-in Create an Alias for the Agent Plug-in Contents 5

6 Configuring an Alias on the Scheduling Manager Chapter 6: Related Documentation 39 CA Workload Automation AE Documentation CA Workload Automation DE Documentation CA Workload Automation ESP Edition Documentation CA Workload Automation CA 7 Edition Documentation Index 43 6 Implementation Guide

7 Chapter 1: Introduction This section contains the following topics: Intended Audience (see page 7) Agents and Agent Plug-ins (see page 7) CA WA Agent for Microsoft SQL Server (see page 9) Supported Number of SQL Server Instances (see page 9) Job Types Supported by CA WA Agent for Microsoft SQL Server (see page 10) Properties Files (see page 10) Intended Audience This document is for system administrators who are responsible for upgrading, installing, and configuring agents. You require knowledge of the operating system where the agent is installed and any third-party products or software technology that the agent uses. Note: The term Windows refers to any Microsoft Windows operating system supported by the agent. Agents and Agent Plug-ins Agents are the key integration components of CA Technologies workload automation products. Agents let you automate, monitor, and manage workload on all major platforms, applications, and databases. To run workload on a particular system, you install an agent on that system. If your workload must run on a UNIX computer, for example, you can install and configure the CA WA Agent for UNIX. The agent lets you run UNIX scripts, execute UNIX commands, transfer files using FTP, monitor file activity on the agent computer, and perform many other tasks. You can extend the functionality of the agent by installing one or more agent plug-ins in the agent installation directory. If you have a relational database such as Oracle, for example, you can install a database agent plug-in to query and monitor the database. Other agent plug-ins are also available. For more information about agent plug-ins, see the Implementation Guide for the appropriate agent plug-in. Note: The agent plug-ins are only available for UNIX, Linux, and Windows operating environments. Chapter 1: Introduction 7

8 Agents and Agent Plug-ins Example: Workload with Different Types of Jobs The following workload contains z/os jobs, a UNIX job, an SAP job, and a Windows job, running on different computers, in different locations, and at different times: 8 Implementation Guide

9 CA WA Agent for Microsoft SQL Server CA WA Agent for Microsoft SQL Server The CA WA Agent for Microsoft SQL Server lets you integrate with SQL Server Agent, a component of Microsoft SQL Server, to automate administrative database tasks. The CA WA Agent for Microsoft SQL Server lets a user perform the following tasks: Submit and monitor the status of SQL Server Agent jobs including Transact-SQL scripts, SQL Server Integration Services (SSIS) packages, or Replication tasks Retrieve a list of jobs on a given Microsoft SQL Server Agent Cancel a running job Read the job log to diagnose errors Get the spool output for a given job or job step The following diagram shows the functional relationship between the scheduling manager, the CA WA Agent for Microsoft SQL Server plug-in, and the Microsoft SQL Server: Supported Number of SQL Server Instances The agent supports simultaneous connections to multiple SQL Server instances, so you can run jobs on multiple instances using a single agent. In Microsoft SQL Server, multiple instances can be installed on a single server. An instance can also span servers, for example, in a High Availability cluster. Each instance can support multiple databases. Note: CA WA Agent for Microsoft SQL Server supports up to 10 SQL Server instances per agent. Chapter 1: Introduction 9

10 Job Types Supported by CA WA Agent for Microsoft SQL Server Job Types Supported by CA WA Agent for Microsoft SQL Server With the CA WA Agent for Microsoft SQL Server, you can define and run the following type of job: SQL Server Agent Lets you execute predefined jobs in the Microsoft SQL Server Agent to perform administrative tasks. The jobs can be Transact-SQL scripts, command prompt applications, Microsoft ActiveX scripts, Integration Services packages, Analysis Services commands and queries, or Replication tasks. Note: Due to a Microsoft SQL Server restriction, the agent cannot run multiple SQL Server Agent jobs with the same name simultaneously. If a SQL Server Agent job is running, you cannot rerun the job until its previous execution finishes. Properties Files The agent uses two properties files to communicate with a SQL Server instance: a system properties file and a target server database properties file. A system properties file, sqlagent.properties, defines default properties for configuring the JDBC connection and filtering the fields displayed in the job spool file. A target server database properties file, target_database.properties, defines the database URL and user credentials that the agent uses to create a JDBC connection to a SQL Server instance. During the installation, a target_database.properties file is created based on the database connection information you provide. After installation, you can create additional target_database.properties files to connect to other instances. The target_database.properties file can also contain optional properties to override properties specified in the system properties file. A property in the target_database.properties file overrides a property with the same name in the sqlagent.properties file. The properties files are located in the config\sql subdirectory of the agent installation directory after you install CA WA Agent for Microsoft SQL Server. More information: Configuring the System Properties File (see page 16) Configuring the Target Server Database Properties File (see page 29) 10 Implementation Guide

11 Chapter 2: Implementation Checklist This section contains the following topics: How to Install and Configure CA WA Agent for Microsoft SQL Server (see page 11) Deciding Whether to Create an Alias (see page 12) How to Install and Configure CA WA Agent for Microsoft SQL Server CA WA Agent for Microsoft SQL Server is an agent plug-in that installs into the CA WA Agent for Windows installation directory. Note: Before installing the agent plug-in, you must install and configure CA WA Agent for Windows. To install and configure the agent plug-in, follow these steps: 1. Review the system requirements in the CA Workload Automation Agent for Microsoft SQL Server Release Notes. 2. Decide whether to create an alias (see page 12). 3. Apply the latest agent patch on the platform where you are installing the agent plug-in. 4. Review the agent plug-in installation options (see page 13). 5. Install the agent plug-in (see page 15). 6. Download the jtds JDBC driver (see page 16). 7. (Optional) Configure the system properties file (see page 16). 8. (Optional) Configure the target server database properties file (see page 29). 9. Configure the scheduling manager to work with the agent plug-in (see page 33). 10. (Optional) Run a verification test (see page 33). Chapter 2: Implementation Checklist 11

12 Deciding Whether to Create an Alias Deciding Whether to Create an Alias You install an agent plug-in into the agent installation directory to extend the core functionality of the agent. By default, the agent plug-in operates under the same agent name that is assigned to the agent. An alias lets you create a unique agent name for an agent plug-in, which is useful for controlling agent security or for setting up clustered environments. The installation program for the agent plug-in generates the alias by adding a suffix to the agent name. Note: If you are installing the agent plug-in to work with CA Workload Automation DE, you must set up an alias. Setting up an alias for use with other scheduling managers is optional. Suppose that you have installed an agent named AGT10 on a Windows computer. Users who have access to that agent through their security permissions specify AGT10 as the agent name in their job definitions. Now suppose that you install an agent plug-in into the installation directory for AGT10. You can create an alias for the agent plug-in, for example, AGT10_MSSQL. You can then restrict access to that alias to only those users that run SQL Server Agent workload. Those specific users then must specify AGT10_MSSQL as the agent name in their job definitions. Each agent plug-in has a default alias that you can enable during installation. For example, the agent plug-in for CA WA Agent for Microsoft SQL Server has the default alias agentname_mssql. You can enable or change the default alias name after installation. To work, you must also configure the alias on the scheduling manager. Note: To configure agent aliasing for clustered environments, see the CA Workload Automation Agent for UNIX, Linux, or Windows Implementation Guide. 12 Implementation Guide

13 Chapter 3: Installing the Agent Plug-in This section contains the following topics: CA WA Agent for Microsoft SQL Server Installation Options (see page 13) Controlling the Agent Plug-in (see page 15) Install the Agent Plug-in Using an Interactive Program (see page 15) Download the jtds JDBC Driver (see page 16) Configuring the System Properties File (see page 16) Configuring the Target Server Database Properties File (see page 29) How to Remove the Agent Plug-in (see page 31) CA WA Agent for Microsoft SQL Server Installation Options The CA WA Agent for Microsoft SQL Server interactive installation program prompts you for the following information: Do you want to configure CA WA Agent for Microsoft SQL Server plug-in? Indicates whether you want to configure the agent plug-in. Y Configures the agent plug-in. Choose this option for a new installation. N Does not configure the agent plug-in. Choose this option for an upgrade. The installer asks you whether to override the system properties (sqlagent.properties) file. Do you want to set up the alias? Indicates whether the default alias is enabled for the agent plug-in. Y Enables the default alias. The default alias for CA WA Agent for Microsoft SQL Server is agentname_mssql. N Disables the default alias. Note: The alias is required for CA Workload Automation DE. Chapter 3: Installing the Agent Plug-in 13

14 CA WA Agent for Microsoft SQL Server Installation Options Default SQL Server destination name Specifies the name of the default SQL Server destination (target_database). To create a JDBC connection to a SQL Server instance, the agent creates a target server database properties file named target_database.properties. Limits: Alphanumeric characters and underscores (_); the first character must be alphabetic Notes: Database host Do not use Sample or Sqlagent as the destination name as these names are reserved. After installation, you can create additional target server database properties files to connect to other SQL Server instances. Specifies the address of the computer where your database is installed. Default: localhost Note: The agent constructs the JDBC URL based on the database connection information you provide. After installation, you can configure the target_database.properties file to use a custom JDBC URL. Database port (Optional) Specifies the database listener port. Note: To use a dynamic port, press Enter to skip this prompt. You will be prompted to enter a database instance name. Database instance name Specifies the database instance name. Note: The database instance name is required to use a dynamic port. If a database port is specified, this prompt is skipped. Default user name (Optional) Specifies the default user that the agent uses to create a JDBC connection to a SQL Server instance. The user can be a Windows domain user for Windows domain authentication or a SQL Server user for SQL Server authentication. Default password Specifies the password for the default user. The agent encrypts the password in the target_database.properties file. Important! To avoid specifying passwords in job definitions using the CLI, we recommend that you set up a default user. As the target_database.properties file can contain encrypted passwords, we recommend that you secure and restrict access to the agent directories and their contents. 14 Implementation Guide

15 Controlling the Agent Plug-in Windows domain name Specifies the Windows domain name for Windows authentication. Note: The Windows domain name is required for Windows domain authentication. If SQL Server authentication is used, press Enter to skip this prompt. Controlling the Agent Plug-in You control the agent plug-in using the agent where the plug-in is installed. Note: For instructions to start and stop the agent, see the CA Workload Automation Agent for UNIX, Linux, or Windows Implementation Guide. Install the Agent Plug-in Using an Interactive Program You can install CA WA Agent for Microsoft SQL Server using an interactive program that prompts you for the required information. To install the agent plug-in using an interactive program 1. Copy the mssql.pak file into the agent installation directory. You can copy this file from the product DVD or download a zip file that contains the file from the CA Support Online website, found at 2. Change to the agent installation directory. For example, type the following command: cd C:\Program Files\CA\WA Agent R11.3 SP1 3. Type the following command to stop the agent: cybagent -s The agent stops. 4. Type the following command to start the installation program: PluginInstaller.exe mssql.pak. 5. Enter the information the installation program prompts you for (see page 13). The installation program displays a message and closes automatically upon a successful installation. Note: The installation program backs up all modified and replaced files. The backup files are compressed into a file named backup_timestamp.zip, located in the backups subdirectory of the agent installation directory. You can use Winzip or other similar utilities to open the backup file. A backup copy of the agentparm.txt file is stored in the zip file. Chapter 3: Installing the Agent Plug-in 15

16 Download the jtds JDBC Driver Download the jtds JDBC Driver Due to a license restriction, you must manually download the jtds JDBC driver and copy it into the agent installation directory before you can complete the installation. To download the jtds JDBC driver 1. Open your browser and go to the following web page: nload The web page opens. 2. Download and unzip the jtds dist.zip file to the agent computer. 3. Copy the jtds jar file into the following location: install_dir\jars\ext install_dir Specifies the agent installation directory. 4. Type the following command to start the agent: cybagent -a The agent starts. Configuring the System Properties File The sqlagent.properties file contains values to configure the JDBC connection and filter the fields displayed in the job spool file. You can change these values in the system properties file if most of your SQL Server instances use the same values. If a SQL Server instance has unique values for these properties, add the properties to the target server database properties file created for that instance to override the default values. The sqlagent.properties file contains the following settings for configuring the JDBC connection: max.retry Specifies the number of times the agent tries to reconnect to the SQL Server instance before reporting a failure. The Retry.interval property controls how long the agent waits between reconnection attempts. Default: 2 16 Implementation Guide

17 Configuring the System Properties File Retry.interval Specifies the interval in seconds between attempts to connect to the SQL Server instance. When "connection refused" occurs during the JDBC call, the agent attempts to reconnect after the specified interval. The max.retry property controls the number of reconnection attempts. Default: 60 seconds monitor.poll.interval Specifies how often in seconds the agent polls the SQL Server database for job execution status information. Default: 60 seconds Note: As you increase the frequency that the agent accesses the SQL Server database, you decrease the available resources SQL Server has to serve other user requests. appendrunlog Specifies whether the job history of the current execution is captured and stored in the spool file for the RunJob CLI operation. The following values are available: *ALWAYS Indicates that the job history is always stored in the spool file for the RunJob operation. *FAILURE *NONE Indicates that the job history is stored in the spool file for the RunJob operation only when the job fails or is canceled. To get the job history for the RunJob operation when the job is successful, use the GetJobHistory operation. Indicates that no job history is stored in the spool file for the RunJob operation. To get the job history for the RunJob operation, use the GetJobHistory operation. Default: *FAILURE db.classname Specifies the name of the JDBC driver the agent uses to create a JDBC connection. Chapter 3: Installing the Agent Plug-in 17

18 Configuring the System Properties File The sqlagent.properties file contains the following settings for filtering the fields displayed in the spool file for each CLI operation: GetJobList Specifies the fields that are displayed in the spool file for the GetJobList operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: job_id name description Note: For the GetJobList operation, the rows displayed in the spool file are sorted based on the order the columns appear in the filter. By default, the rows are sorted by job_id first, followed by name. If GetJobList=name job_id description, the rows are sorted by name first, followed by job_id. GetJobDetail Specifies the fields that are displayed in the spool file for the GetJobDefault operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: job_id originating_server name enabled description category owner date_modif ied GetJobStep Specifies the fields that are displayed in the spool file for the GetJobStep operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: step_id step_name subsystem command GetJobTargetServer Specifies the fields that are displayed in the spool file for the GetJobTargetServer operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: server_id server_name enlist_date GetJobHistory Specifies the fields that are displayed in the spool file for the GetJobHistory operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: step_id step_name sql_message_id sql_severity message run_status run_date r un_time run_duration 18 Implementation Guide

19 Configuring the System Properties File GetStepLog Specifies the fields that are displayed in the spool file for the GetStepLog operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: *ALL GetJobStatus Specifies the fields that are displayed in the spool file for the GetJobStatus operation. Separate each field with a vertical bar ( ). To display all available fields (see page 21), specify *ALL. Default: job_id originating_server name last_run_date last_run_time last_run_outcome current_execution_status current_execution_step current_retry_attempt type Example: Default System Properties This example shows the default system properties in the sqlagent.properties file: #this properties file defines general configuration that's applied to all target #database #the following property defines the class used to create jdbc connection db.classname=net.sourceforge.jtds.jdbc.driver #the following properties defines the column(s) that will be viewable to end user #for command GetJobList GetJobList=job_id name description #the following properties defines the column(s) that will be viewable to end user #for command GetJobDetail GetJobDetail=job_id originating_server name enabled description category owner da te_modified #the following properties defines the column(s) that will be viewable to end user #for command GetJobStep GetJobStep=step_id step_name subsystem command #the following properties defines the column(s) that will be viewable to end user #for command GetJobTargetServer GetJobTargetServer=server_id server_name enlist_date Chapter 3: Installing the Agent Plug-in 19

20 Configuring the System Properties File #the following properties defines the column(s) that will be viewable to end user #for command GetJobHistory GetJobHistory=step_id step_name sql_message_id sql_severity message run_status ru n_date run_time run_duration #the following properties defines the column(s) that will be viewable to end user #for command GetStepLog GetJobStepLog=*ALL #the following properties defines the column(s) that will be viewable to end user #for command GetJobStatus GetJobStatus=job_id originating_server name last_run_date last_run_time last_run_ outcome current_execution_status current_execution_step current_retry_attempt typ e #this property defines the maximum number of reconnect attempt agent would make if #"connection refused" error happens max.retry=2 #this property defines the number of seconds agent wait between every reconnect #attempt if "connection refused" error happens Retry.interval=60 #this property defines the number of seconds agent should pool sql server database #for job execution status. monitor.poll.interval=60 More information: Properties Files (see page 10) 20 Implementation Guide

21 Configuring the System Properties File Available Fields in Spool File Output by Operation You can configure the sqlagent.properties file to change the fields that are displayed for each CLI operation. Note: The properties in the sqlagent.properties file apply to all target databases. If you want to change the fields for a particular target database, copy the properties that you want to change into the corresponding target_db.properties file and make the changes there. A property in the target_database.properties file overrides a property with the same name in the sqlagent.properties file. The following sections describe the available fields that can be displayed in the spool file for each CLI operation. Not all of the available fields are included in the output by default. The GetJobList operation can display the following fields: job_id Specifies the unique ID for the job. originating_server name enabled Specifies the name of the server the job belongs to. Specifies the name of the job. Indicates whether the job is enabled to be executed. description Specifies the job description. category owner Specifies the job category. Specifies the job owner. date_modified Specifies the date that the job was last modified. Note: By default, the job_id, name, and description fields are included in the output. The GetJobDetail operation can display the following fields: job_id Specifies the unique ID for the job. Chapter 3: Installing the Agent Plug-in 21

22 Configuring the System Properties File originating_server Specifies the name of the server the job belongs to. name Specifies the name of the job. enabled Indicates whether the job is enabled to be executed. description Specifies the job description. category Specifies the job category. owner Specifies the job owner. date_modified Specifies the date that the job was last modified. Note: By default, all the available fields are included in the output. The GetJobStep operation can display the following fields: step_id Specifies the job step ID. step_name Specifies the name of the step. subsystem Specifies the name of the subsystem where the step command executes. command Specifies the name of the command to execute. flags Specifies a bitmask of values that control step behavior. cmdexec_success_code (CmdExec steps only) Specifies the process exit code of a successful command. 22 Implementation Guide

23 Configuring the System Properties File on_success_action Specifies the action to take if the step succeeds. Options are as follows: Quits with success. Quits with failure. Goes to the next step. Goes to the step indicated by the on_success_step_id field. on_success_step_id Indicates the next step to execute when the on_success_action field is set to 4. on_fail_action Specifies the action to take if the step fails. Options are as follows: on_fail_step_id server Quits with success. Quits with failure. Goes to the next step. Goes to the step indicated by the on_fail_step_id field. Indicates the next step to execute when the on_fail_action field is set to 4. Reserved. database_name (Transact-SQL steps only) Specifies the database where the command executes. database_user_name (Transact-SQL steps only) Specifies the database user context where the command executes. Chapter 3: Installing the Agent Plug-in 23

24 Configuring the System Properties File retry_attempts Specifies the maximum number of times that the command is retried (if it is unsuccessful) before the step is deemed to have failed. retry_interval Specifies the interval in minutes between retry attempts. os_run_priority Reserved. output_file_name (Transact-SQL and CmdExec steps only) Specifies the file that the command output is written to. last_run_outcome Specifies the outcome of the step the last time it ran. Options are as follows: Indicates the step failed. Indicates the step succeeded. Indicates the step was canceled. Indicates the status was unknown. last_run_duration Specifies the duration in seconds of the step the last time it ran. last_run_retries Specifies the number of times the command was retried the last time that the step ran. last_run_date Specifies the date when the step last started execution. last_run_time Specifies the time when the step last started execution. proxy_id Specifies the proxy for the job step. Note: By default, the step_id, step_name, subsystem, and command fields are included in the output. 24 Implementation Guide

25 Configuring the System Properties File The GetJobTargetServer operation can display the following fields: server_id Specifies the identifier of the target server. server_name Specifies the computer name of the target server. enlistdate Specifies the date that the target server was enlisted into the master server. Note: By default, all the available fields are included in the output. The GetJobStatus operation can display the following fields: job_id Specifies the unique ID for the job. originating_server Specifies the name of the server the job belongs to. name Specifies the name of the job. LastRunDateTime Specifies the last time the job ran in the format YYYY-MM-DD HH:MM:SS. LastRunOutcome Specifies the outcome of the job the last time it ran. Options are as follows: 0 Indicates the job failed. 1 Indicates the job succeeded. 3 Indicates the job was canceled. 5 Indicates the status was unknown. Chapter 3: Installing the Agent Plug-in 25

26 Configuring the System Properties File CurrentExecutionStatus Indicates the current execution status of the job. Options are as follows: Indicates that the job is executing. Indicates that the job is waiting for a thread. Indicates that the job is between retries. Indicates that the job is idle. Indicates that the job is suspended. Indicates that the job is performing completion actions. CurrentExecutionStep Specifies the step that is currently running. CurrentRetryAttempt Type Specifies the current retry attempt if the job is running and the step has been retried. Species the type of job. Options are as follows: Indicates that the job has no target servers. Indicates a local job. Indicates a multiserver job. Note: By default, all the available fields are included in the output. The GetJobHistory operation can display the following fields: instance_id Specifies the history entry identification number. 26 Implementation Guide

27 Configuring the System Properties File job_id Specifies the unique ID for the job. job_name step_id Specifies the name of the job. Specifies the job step ID. step_name Specifies the name of the step. sql_message_id (Transact-SQL steps only) Specifies the most recent Transact-SQL error number encountered while running the command. sql_severity (Transact-SQL steps only) Specifies the highest Transact-SQL error severity encountered while running the command. message Specifies the job or step history message. run_status Specifies the outcome of the job or step. run_date Specifies the date the job or step began executing. run_time Specifies the time the job or step began executing. run_duration Specifies the elapsed time in the execution of the job or step in the format HHMMSS. operator_ ed Specifies the operator who was ed regarding this job (is NULL for step history). operator_netsent Specifies the operator who was sent a network message regarding this job (is NULL for step history). operator_paged Specifies the operator who was paged regarding this job (is NULL for step history). Chapter 3: Installing the Agent Plug-in 27

28 Configuring the System Properties File retries_attempted server Specifies the number of times the step was retried (always 0 for job history). Specifies the server the step or job executes on. Is always (local). Note: By default, the step_id, step_name, sql_message_id, sql_severity, message, run_status, run_date, run_time, and run_duration fields are included in the output. The GetStepLog operation can display the following fields: job_name step_id Specifies the name of the job. Specifies the job step ID. step_name Specifies the name of the step. step_uid Specifies the unique identifier of the step (system-generated) in the job. date_created Specifies the date that the step was created. date_modified log_size Log Specifies the date that the step was last modified. Specifies the size of the job step log in megabytes (MB). Specifies the job step log output. Note: By default, all the available fields are included in the output. 28 Implementation Guide

29 Configuring the Target Server Database Properties File Configuring the Target Server Database Properties File During installation, a target server database properties file (target_database.properties) is created based on the database connection information you provided. You can configure the target_database.properties files to change the values that you chose during installation or create additional target_database.properties files to connect to other instances. Note: When naming the target server database properties file, use only alphanumeric characters and underscores (_). The first character must be alphabetic. If the target database is specified in the job definition, the agent uses the corresponding properties file. For example, if localdb is specified in the job definition, the agent uses the localdb.properties file to connect to the SQL Server instance. If the target database is not specified in the job definition, the agent uses the default value specified in the mssql.default.targetdb parameter in the agentparm.txt file. For example, if the mssql.default.targetdb parameter is set to defaultdb, the agent uses the defaultdb.properties file to connect to the SQL Server instance. You can also override a default property in the system properties file by defining the property in the target_database.properties file. A system property that is defined in the target_database.properties file overrides the value of the same property in the system properties file. In addition to the properties defined in the system properties file, the target_database.properties file can contain the following properties: db.url Specifies the JDBC URL. The agent constructs the JDBC URL based on the database connection information you provided during installation. You can modify this property to use a custom JDBC URL. Example: jdbc:jtds:sqlserver://localhost:1433/msdb Note: If you are using a dynamic port, the database instance name is required, for example: jdbc.jtds.sqlserver://remotehost/msdb;instance=prodinstance. db.username Specifies the user that the agent uses to create a JDBC connection to a SQL Server instance. The user can be a Windows domain user for Windows domain authentication or a SQL Server user for SQL Server authentication. Chapter 3: Installing the Agent Plug-in 29

30 Configuring the Target Server Database Properties File db.password Specifies the password for the user name. Important! To avoid specifying passwords in job definitions using the CLI, we recommend that you set up a default user. As the target_database.properties file can contain encrypted passwords, we recommend that you secure and restrict access to the agent directories and their contents. Note: The password must be encrypted. To encrypt a password, use the Password utility that is provided with the agent. For more information about the Password utility, see the CA Workload Automation Agent for UNIX, Linux, or Windows Implementation Guide. db.domain Specifies the Windows domain name for Windows authentication. Notes: If the db.domain argument is specified, the agent assumes that the db.username property contains the Windows domain user. In this case, Windows domain authentication is used. If the db.domain argument is not specified, the agent assumes that the db.username property contains the SQL Server user. In this case, SQL Server authentication is used. Example: Windows Domain Authentication This example shows a target_database.properties file that uses Windows domain authentication: db.url=jdbc:jtds:sqlserver://localhost:1433/msdb db.username=auser db.password=3b38ca1614d55535 db.domain= MYDOMAIN Example: Dynamic Port This example shows the previous target_database.properties file using a dynamic port: db.url=jdbc:jtds:sqlserver://localhost/msdb;instance=mydbinstance db.username=auser db.password=3b38ca1614d55535 db.domain= MYDOMAIN More information: Properties Files (see page 10) 30 Implementation Guide

31 How to Remove the Agent Plug-in How to Remove the Agent Plug-in You can remove an agent plug-in when you no longer require it. To remove the agent plug-in, follow these steps: 1. Disable the agent plug-in (see page 31). 2. (Optional) Remove the agent plug-in from the scheduling manager (see page 32). Disable CA WA Agent for Microsoft SQL Server Use this procedure when you want to remove CA WA Agent for Microsoft SQL Server from your system. To disable CA WA Agent for Microsoft SQL Server 1. Verify that all workload is complete. 2. Stop the agent. 3. Open the agentparm.txt file located in the agent installation directory. 4. Comment out the plugins.start_internal_n=sql parameter. 5. Renumber all other agent plug-ins that are assigned a greater number than the agent plug-in you are uninstalling. 6. Comment out the communication.alias parameter if you created an alias during the agent plug-in installation. 7. Renumber any subsequent communication.alias_n parameters. 8. Save and close the agentparm.txt file. 9. Remove the sql.jar file from the jars subdirectory of the agent installation directory. 10. Start the agent. Chapter 3: Installing the Agent Plug-in 31

32 How to Remove the Agent Plug-in Example: Renumber the plugins.start_internal_n Parameter Suppose you have the following agent plug-ins set in the agentparm.txt file: plugins.start_internal_1=runner plugins.start_internal_2=sql plugins.start_internal_3=ftp plugins.start_internal_4=microfocus To disable the agent plug-in for CA WA Agent for Microsoft SQL Server, you would modify the agentparm.txt file as follows: plugins.start_internal_1=runner #plugins.start_internal_2=sql plugins.start_internal_2=ftp plugins.start_internal_3=microfocus Example: Renumber the communication.alias_n Parameter Suppose you have two alias agent plug-ins. The agentparm.txt file has the following parameters: communication.alias_1=agentname_mssql communication.alias_2=agentname_mf To disable the agent plug-in for CA WA Agent for Microsoft SQL Server, modify the agentparm.txt file as follows: #communication.alias_1=agentname_mssql communication.alias_1=agentname_mf Remove the Agent Plug-in from the Scheduling Manager In addition to disabling the agent plug-in, you can remove it from the configuration on the scheduling manager. Note: For detailed instructions to remove the agent from the scheduling manager, see the documentation for your scheduling manager. 32 Implementation Guide

33 Chapter 4: Your Scheduling Manager and the Agent Plug-in This section contains the following topics: Configuring the Scheduling Manager to Work with the Agent Plug-in (see page 33) Running a Verification Test (see page 33) Configuring the Scheduling Manager to Work with the Agent Plug-in If you have defined the following items for the agent plug-in, you must configure the items on the scheduling manager: An alias A user For detailed configuration instructions, see the documentation for your scheduling manager. Running a Verification Test For your verification test, you define and run a SQL Server Agent job. To define the job, you require the following information: Agent Specifies the name of your agent or the alias for the agent plug-in if you created an alias. Operation Job ID (CLI only) Specifies the CLI operation. To run a SQL Server Agent job using the CLI, specify RunJob. Specifies the internal job identification number. Specify the job ID or the job name, but not both. Chapter 4: Your Scheduling Manager and the Agent Plug-in 33

34 Running a Verification Test Job name Specifies the job name. Specify the job ID or the job name, but not both. For more information about running a SQL Server Agent job, see the documentation for your scheduling manager or the CLI User Guide. 34 Implementation Guide

35 Chapter 5: Configuring the Agent Plug-in This section contains the following topics: How to Configure Agent Parameters (see page 35) CA WA Agent for Microsoft SQL Server Parameters in the agentparm.txt File (see page 36) How to Set Up an Alias for the Agent Plug-in (see page 37) How to Configure Agent Parameters You configure agent parameters by editing the agentparm.txt file, located in the agent installation directory. When you install the agent, the installation program adds frequently-configured agent parameters to the file. Other agent parameters exist, which you must manually add to the agentparm.txt file to configure the agent. For any configuration changes to take effect, always stop and restart the agent. For some agent parameters, such as the agent name and communication parameters, also configure the parameters on the scheduling manager. To configure agent parameters, do the following: 1. Configure agent parameters on the agent (see page 35). 2. Configure agent parameters on the scheduling manager (see page 36). Configure Agent Parameters on the Agent Use the following procedure to configure agent parameters on CA WA Agent for UNIX, Linux, or Windows. To configure agent parameters on the agent 1. Change to the agent installation directory. 2. Stop the agent. At the command prompt, enter the following command: On UNIX:./cybAgent -s On Windows: cybagent -s The agent stops. Chapter 5: Configuring the Agent Plug-in 35

36 ge CA WA Agent for Microsoft SQL Server Parameters in the agentparm.txt File 3. Open the agentparm.txt file located in the agent installation directory. 4. Edit the parameters to make the required changes. 5. Save and close the agentparm.txt file. 6. Start the agent. At the command prompt, enter the following command: On UNIX:./cybAgent & On Windows: cybagent -a The agent starts and the parameters are configured. Configure Agent Parameters on the Scheduling Manager When you change an agent parameter in the agentparm.txt file that is also defined on the scheduling manager, such as the agent name, configure the agent parameter on the scheduling manager. Note: For detailed instructions to configure agent parameters on the scheduling manager, see the documentation for your scheduling manager. CA WA Agent for Microsoft SQL Server Parameters in the agentparm.txt File The agent plug-in installation program adds the parameters listed below to the agentparm.txt file. The file is located in the agent installation directory. You can open the agentparm.txt file in any standard text editor. Note: You must save the file after making edits to persist the changes. communication.alias_n Defines the alias name for the agent. The n suffix increments sequentially for each alias agent. Note: To enable an alias on the agent, verify that the comment character (#) is removed from the parameter line. Default: agentname_mssql 36 Implementation Guide

37 How to Set Up an Alias for the Agent Plug-in plugins.start_internal_n Specifies the agent plug-in to start by the core Java agent. n Denotes an integer assigned to the agent plug-in, starting at 1. The n suffix must increase sequentially for each agent plug-in. mssql.default.targetdb Specifies the default target server database (target_database). If the target database is not specified in the job definition, the agent retrieves the JDBC connection information from the corresponding property file (target_database.properties) stored on the agent. How to Set Up an Alias for the Agent Plug-in When you install the agent plug-in, you are prompted to create a default alias, which you can change after installation. If you enable an alias on the agent plug-in, you must also configure the alias on the scheduling manager. To set up an alias for the agent plug-in, follow these steps: 1. Create an alias for the agent plug-in (see page 37). 2. Configure the alias on the scheduling manager (see page 38). Create an Alias for the Agent Plug-in An alias lets you create a unique agent name for an agent plug-in. Each agent plug-in has a default alias, which you can enable or change. To create an alias for the agent, configure the following agent parameter on the agent: communication.alias_n Defines the alias name for the agent. The n suffix increments sequentially for each alias agent. Note: To enable an alias on the agent, verify that the comment character (#) is removed from the parameter line. More information: Configure Agent Parameters on the Agent (see page 35) Chapter 5: Configuring the Agent Plug-in 37

38 How to Set Up an Alias for the Agent Plug-in Configuring an Alias on the Scheduling Manager When you create an alias for an agent plug-in, you must also configure the alias on the scheduling manager. You must define the alias on the scheduling manager with the same address, port number, and encryption key as the agent where the agent plug-in is installed. Note: For detailed instructions to configure an alias on the scheduling manager, see the documentation for your scheduling manager. 38 Implementation Guide

39 Chapter 6: Related Documentation Documentation for the agent and scheduling managers is available in PDF format at Note: To view PDF files, you must download and install the Adobe Reader from the Adobe website if it is not already installed on your computer. This section contains the following topics: CA Workload Automation AE Documentation (see page 39) CA Workload Automation DE Documentation (see page 40) CA Workload Automation ESP Edition Documentation (see page 40) CA Workload Automation CA 7 Edition Documentation (see page 41) CA Workload Automation AE Documentation To work with the agent and CA Workload Automation AE, see the following documentation: Task Configure the scheduling manager to work with the agent Define, monitor, and control jobs Documentation CA Workload Automation AE UNIX Implementation Guide CA Workload Automation AE Windows Implementation Guide CA Workload Automation AE Reference Guide CA Workload Automation AE User Guide CA Workload Control Center Workload Scheduling Guide Chapter 6: Related Documentation 39