Query SQL optional parameters

Optional parameters follow the query sql command and positional parameters.

/COMPATibilityinfo

For query operations, this parameter displays information that is related to the compatibility of a backup object with a SQL Server. Certain SQL Server configuration options must be compatible before you can restore a backup object to a SQL Server. When you specify this parameter, SQL and IBM Storage Protect Snapshot for SQL Server configuration information is listed to help you determine whether a backup object is correct for a SQL Server.

Considerations:

Compatible generally means identical. However, if you use a binary sort order for both the SQL Server and the backup object, the code pages might be different, although the interpretation of individual character values might result in different characters that are displayed or printed.

/CONFIGfile=configfilename

Use the /configfile parameter to specify the name (configfilename) of the IBM Storage Protect Snapshot for SQL Server configuration file that contains the values to use for a query sql operation.

The configfilename variable can include a fully qualified path. If the configfilename variable does not include a path, the IBM Storage Protect Snapshot for SQL Server installation directory is used. If the /configfile parameter is not specified, or if the configfilename variable is not specified, the default value is tdpsql.cfg.

If the configfilename variable includes spaces, enclose the entire /configfile parameter entry in double quotation marks. For example:

/CONFIGfile="c:\Program Files\file.cfg"

See Set positional parameters for descriptions of available configuration parameters.

/LOGFile=logfilename

Use the /logfile parameter to specify the name of the activity log file that is generated by IBM Storage Protect Snapshot for SQL Server. The logfilename variable identifies the name of the activity log file. If the specified log file does not exist, a new log file is created. If the specified log file exists, new log entries are appended to the file. The logfilename variable can include a fully qualified path. However, if no path is specified, the log file is written to the IBM Storage Protect Snapshot for SQL Server installation directory. If the logfilename variable includes spaces, enclose the entire /logfile parameter entry in double quotation marks. For example:

/LOGFile="c:\Program Files\mytdpsql.log"

If the /logfile parameter is not specified, log records are written to the default log file, tdpsql.log. The /logfile parameter cannot be turned off, logging always occurs.

When you use multiple simultaneous instances of IBM Storage Protect Snapshot for SQL Server to run operations, use the /logfile parameter to specify a different log file for each instance used. This function directs logging for each instance to a different log file and prevents interspersed log file records. Failure to specify a different log file for each instance can result in unreadable log files.

/LOGPrune=numdays|No

When you prune log data, you can discard some of the generated logs according to detailed filtering criteria that you set. Depending on the option that you set for the /LOGPrune parameter, a certain number of days of data are saved. By default, 60 days of log entries are saved. The option No can be entered to disable log pruning.

Regardless of the option that you set for this parameter, you can explicitly request log pruning at any time.

Considerations:

For numdays, the range is 0 to 9999. A value of 0 deletes all entries in the activity log file except for the current command entries.
If you specify no, the log file is not pruned.
If you do not specify /LOGPrune, the default value is that specified by the logprune configurable option in the configuration file. The default value is 60.
If you specify /LOGPrune, its value is used instead of the value that is stored in the configuration file. Specifying this parameter does not change the value in the configuration file.
You can specify /LOGPrune without specifying numdays or no; in this case, the default value, 60, is used.
Changes to the value of the TIMEformat or DATEformat parameter can result in an unwanted pruning of the log file. If you are running a command that might prune the log file, and the value of the TIMEformat or DATEformat parameter is changed, complete one of the following to prevent unintentional pruning of the log file:
- Make a copy of the existing log file.
- Specify a new log file with the /LOGFile parameter or logfile setting.

/SQLAUTHentication=INTegrated | SQLuserid

This parameter specifies the authorization mode that is used when you log on to the SQL Server. The integrated value specifies Windows authentication. The user ID you use to log on to Windows is the same ID you use to log on to the SQL Server. This option is the default value. Use the sqluserid value to specify SQL Server user ID authorization. The user ID specified by the /sqluserid parameter is the ID you use to log on to the SQL Server. Any SQL user ID must have the SQL Server SYSADMIN fixed server role.

/SQLCHECKSum=No|Yes

Use the SQLCHECKSum parameter to verify the integrity of a legacy database backup.

You can specify the following values:

No: Do not enable the checksum option for a legacy database backup. This option is the default option.
Yes: Enable the checksum option to verify that a legacy database backup is consistent and correct.

/SQLPassword=sqlpasswordname

This parameter specifies the SQL password that IBM Storage Protect Snapshot uses to log on to the SQL Server that objects are backed up from or restored to.

Considerations:

Using this parameter means that you are using SQL Server authentication. The SQL Server and the SQL user ID for this password must both be configured for SQL Server authentication.
If you do not specify /sqlpassword, the default value is blank (" ").
If you specify /sqlpassword but not sqlpasswordname, the default is also blank (" ").
This parameter is ignored if you use the /sqlauth=integrated parameter with it.

/SQLSERVer=sqlserver-connection

The /sqlserver parameter specifies the SQL Server that Data Protection for SQL Server logs on to. The sqlserver-connection comprises the sqlprotocol and sqlservername. The sqlprotocol variable specifies the communication protocol to use and with this variable, you can specify an sqlservername. You can check the SQL connection by using the SQL Server Configuration Manager tool (under SQL Server Native Client Configuration client protocols). You can choose from the following protocols:

Table 1. Table 1. SQL Server connection protocols
Protocol Name	Description	Example Usage (with sqlserver-connection details)
lpc	Shared Memory	/sqlserver=lpc:<servername>\<instancename>
np	Named Pipes	/sqlserver=np:<servername>\pipe You can optionally specify a specific named pipe instance. For example, /sqlserver=np: \\hostname\pipe\pipe name By default, the pipe name is sql\query. If you connect to a named instance, the pipe name is typically in the following format: \\<servername>\pipe\MSSQL$<instancename>\SQL\query
tcp	Transmission Control	/sqlserver=[tcp:]<servername>[\<instancename>][,port]
via	Virtual Interface Adapter	/sqlserver=via:<virtualservername>[\<instancename>]

Attention:

For tcp protocols only, you have the option of defining a port. If you do not define a port, the default port value is the SQL default port 1433.
For the via protocol, SQL Server supports this protocol only through SQL Server 2008 R2.
To enable Data Protection for SQL Server to communicate with AlwaysOn Availability Group (AAG) instances, it is not possible to connect to the SQL Server using AAG listeners. For backup and restore operations, you must use the local SQL Server instance name (or instance name and port number) to communicate with the AAG. For AAG (or non-AAG instances), you can also specify non-default port numbers.

If you do not specify a protocol, Data Protection for SQL Server logs on to the SQL Server according to the first protocol that becomes available.

Considerations:

The default value is the value specified by the SQL Server configurable option in the Data Protection for SQL Server configuration file. This is initially the local computer name.
If you specify /sqlserver but not sqlservername, the local computer name is used.
The following two shortcuts are accepted as the local computer name: . (local) That is, a period or the word local within parentheses.
If the SQL Server is a member of a fail-over cluster, the CLUSTERNODE option in the IBM Storage Protect options file must have the value YES.
If the SQL Server is not the default instance or is a member of a fail-over cluster, you must specify the name.
The format of sqlservername depends on what type of instance it is and whether it is clustered or not:
Format Instance? Clustered? Name required?
local-computername default no no
local-computername\instancename named no yes
virtualservername default yes yes
virtualservername\instancename named yes yes

Format	Instance?	Clustered?	Name required?
local-computername	default	no	no
local-computername\instancename	named	no	yes
virtualservername	default	yes	yes
virtualservername\instancename	named	yes	yes

localcomputername: The network computer name of the computer on which the SQL Server and Data Protection for SQL Server reside. The TCP/IP host name may not always be the same.
instancename: The name given to the named instance of the SQL Server that is specified during installation of the instance.
virtualservername: The name given to the clustered SQL Server that is specified during clustering service setup. This name is not the cluster or node name.

/SQLUSer=sqlusername

The /sqluser parameter specifies the name that IBM Storage Protect Snapshot uses to log on to the SQL Server.

Considerations:

Using this parameter means that you are using SQL Server authentication. The SQL Server and the SQL user ID for this password must both be configured for SQL Server authentication.
The SQL user ID must have the SQL Server SYSADMIN fixed server role.
If you do not specify /sqluser, the default is sa.
If you specify /sqluser but not sqlusername, the default is also sa.
This parameter is ignored if you use the /sqlauth=integrated parameter with it.