SQL Server 2012 : Configuration Options (part 2) - Startup Parameters

2. Start/Stop Configuration Properties

The startup configuration properties, described in Table 1, control how SQL Server and the processes are launched.

Table 1 Start/Stop Configuration Properties

2.1 Startup Parameters

You use the startup parameters with the SQL Server services. The startup parameters are passed as parameters to the SQL Server program when the SQL Server service is started. Although you can add startup parameters from Services console, it's highly recommend that you use the SQL Server Configuration Manager, as shown in Figure 1. One of the main reasons has to do with minimizing downtime. Configuration Manager enables you to add startup parameters with the SQL Server service still running. You can restart the service during a maintenance window and minimize downtime. Also, Configuration manager is the only method for SQL Server failover clustering instance because it is a cluster-aware tool, and services console is not.

Figure 1 Add startup parameters to the SQL Server service to change its behavior.

To add the startup parameters in SQL Server Configuration Manager, follow these steps:

In addition to the standard master database-location parameters, two parameters are particularly useful:

• -m: Starts SQL Server in single-user mode. This is required to restore the master database.
• -f: Starts up with a minimal configuration.

Additional startup parameters are as follows:

• -d: Includes the full path of the master database file, with no spaces between the d and the path.
• -l: Includes the full path of the master database log file, with no spaces between the l and the path.
• -e: Includes the full path of the SQL Server error log file, with no spaces between the e and the path.
• -c: Starts SQL Server so that it is not running as a Windows service.
• -x: Enables maximum performance by disabling monitoring features. Because the monitoring features are disabled, your ability to troubleshoot performance and functional problems is greatly reduced.
• -g: Specifies virtual memory (in MB) available to SQL Server for memory allocations within the SQL Server process, but outside the SQL Server memory pool (extended procedure .dll files, OLE DB providers referenced by distributed queries, and automation objects referenced in Transact-SQL statements).
• -n: Disables logging to the Windows application log.
• -s: Starts a named instance of SQL Server. The instance name follows directly after the s, with no spaces in between.
• -Ttrace#: Enables trace-specific flags by trace flag number. Using trace flags for an extended period of time is not recommended. Use trace flags for troubleshooting SQL Server issues and remove them when the issue is resolved. Also, never use undocumented trace flags because they can cause more damage than they can provide assistance with any issue.
• -h: Assuming your hardware enables you to add physical memory without restarting the server, use this option to enable SQL Server to immediately begin using the hot add memory. This is only available on the SQL Server Enterprise Edition and can be used on 64-bit SQL Server and 32-bit SQL Server with AWE enabled.

2.2 Startup Stored Procedures

You can figure SQL Server to scan for a startup stored procedure every time the SQL Server starts — similar to how Microsoft DOS operating systems scan for the autoexec.bat file when they boot up. All the startup procedures need to be in the master database, but there is no limit on the number of startup procedures. The key is to remember that each startup procedure consumes one worker thread while executing it. To mark an existing stored procedure to execute automatically when SQL Server starts, use the sp_procoption system stored procedure as follows:

EXEC sp_procoption @ProcName = ‘ExistingSP', 
       @OptionName = ‘startup', 
       @OptionValue = ‘on';

You use the same sp_procoption system stored procedure to stop a stored procedure from executing at SQL Server startup as follows:

EXEC sp_procoption @ProcName = ‘ExistingSP', 
       @OptionName = ‘startup', 
       @OptionValue = ‘off';

Although you can individually mark a stored procedure for automatic execution at SQL Server startup, you can further control the execution of all the startup stored procedures by using the scan for startup procs configuration option. If this option is set to 1, SQL Server scans for and runs all stored procedures marked for automatic execution at startup. An example of a use case for a startup stored procedure would be if you have an expensive query that takes a long time to run at first execution. By using a startup stored procedure to execute this query at startup, it pushes the data into memory for quick access for subsequent requests. It should be noted that while this is a way to “warm the cache” with data, this particular method should be used carefully. While in theory it's possible to do this for multiple tables, you may find yourself pushing the physical resources (i.e. memory) fairly quickly or accidently pushing other items you've loaded out of cache if you're not careful.

The default value of this option is 0, which skips automatic execution of startup stored procedures. The scan for startup procs configuration option is automatically set to 1 when you execute sp_procoption to mark the first stored procedure for automatic execution and is set to 0 when you unmark the last stored procedure for automatic execution. Use the following code to skip automatic execution for all startup stored procedures:

EXEC sp_configure ‘scan for startup procs', 0;
RECONFIGURE;