SQL Server 2008 Tips

By

The Technocrats

Know How and When to Use Emergency Mode Repair

EMERGENCY mode is used when the transaction log for the database has been damaged and no backups are available to restore
from. In this case, regular repairs do not work—repairs are fully logged and this cannot occur if the transaction log is damaged.
In SQL Server 2000 and earlier, EMERGENCY mode was undocumented and was used to allow the transaction log to be rebuilt using
the undocumented DBCC REBUILD_LOG command. Unfortunately, this procedure became publicized on the Internet but usually
without all necessary steps. For this reason, the dev team decided to add a documented and supported method of rebuilding a
transaction log and recovering the database in SQL Server 2005. The feature is called emergency mode repair and its mechanism is
unchanged for SQL Server 2008.
When the database is in EMERGENCY mode and SINGLE_USER mode, and DBCC CHECKDB is run with the
REPAIR_ALLOW_DATA_LOSS option, the following steps are taken:
1. Force recovery to run on the transaction log (if it exists).

This is essentially recovery with CONTINUE_AFTER_ERROR, in a similar vein to using CONTINUE_AFTER_ERROR with either BACKUP
or RESTORE. The idea behind this is that the database is already inconsistent because either the transaction log is corrupt or
something in the database is corrupt in such a way that recovery cannot complete.

Given that the database is inconsistent and the transaction log is about to be rebuilt, it makes sense to salvage as much
transactional information as possible from the log before it is discarded and a new one is created.

This recovery with CONTINUE_AFTER_ERROR functionality is possible only from within DBCC CHECKDB.

2. Rebuild the transaction log if it is corrupt.

3. Run the full set of consistency checks on the database with the REPAIR_ALLOW_DATA_LOSS option.

4. Bring the database online.

Configure Remote Server Connections

Connections from other servers are handled differently than user connections. You can determine whether or not servers can
connect to this server, how long it takes for remote queries to time out, and if distributed transactions are used. To configure
remote connections, do the following:
1. In the Server Properties dialog box, go to the Connections page.

2. To allow servers to connect to this server, select the option Allow Remote Connections To This Server. Remote servers can then
log on to the server to execute stored procedures remotely. You must stop and then start the SQL Server instance to apply the
change if you select this option.
Beware: Remote procedure call (RPC) connections are allowed by default. If you change this behavior, remote servers cannot log
on to SQL Server. This setting change keeps SQL Server secure from remote server access.

3. By default, queries executed by remote servers time out in 600 seconds. To change this behavior, type a time-out value in the
Remote Query Timeout box on the Connections page. Time-out values are set in seconds, and the acceptable range of values is
from 0 through 2,147,483,647. A value of 0 means that there is no query time-out for remote server connections.

4. Stored procedures and queries executed on the server can be handled as distributed transactions by using Distributed
Transaction Coordinator (DTC). If you want to execute procedures this way, select the Require Distributed Transactions For Server-
To-Server Communication check box. If you change this option, you must stop and then start the SQL Server instance.

5. Click OK.
These options can also be set with sp_configure. The related Transact-SQL statements are:

exec sp_configure "remote access", <0 or 1>

exec sp_configure "remote query timeout", <number of seconds>
 exec sp_configure "remote proc trans", <0 or 1>

Note: A value of 0 turns a remote server connection option off, and a value of 1 turns an option on.

Upgrade SQL Server 2000 Log Shipping to SQL Server 2008

Unlike SQL Server 2000 log shipping, which is configured using maintenance plans, SQL Server 2008 log shipping is configured as
part of the standard database properties. Because of this, you cannot directly update SQL Server 2000 log shipping to SQL Server
2008 log shipping. You can, however, migrate your SQL Server 2000 log shipping configuration to SQL Server 2008 log shipping.
To upgrade the log shipping configuration easily, complete the following steps:
1. Upgrade all secondary server instances to SQL Server 2008. When you upgrade the secondary server instances, any log shipping
databases will remain SQL Server 2000 databases because they will be in an offline state.
2. Upgrade the primary server to SQL Server 2008. The primary database will be unavailable while the upgrade is in progress, and
you will not be able to failover to a secondary server.
3. Enable the primary database for log shipping. To ensure that backup logs are applied properly, use the same backup share that
you used with your SQL Server 2000 log shipping configuration.
4. Specify the secondary servers. In the Secondary Database Settings dialog box, you must select the option No, The Secondary
Database Is Initialized during the configuration. The secondary database is upgraded automatically to a SQL Server 2008 database
when you start shipping logs.
SQL Server 2008 does not use any of the log shipping tables used by SQL Server 2000. After the migration, you can remove the
following SQL Server 2000 log shipping tables:

log_shipping_databases
log_shipping_monitor
log_shipping_plan_databases
log_shipping_plan_history
log_shipping_plans
log_shipping_primaries
log_shipping_secondaries

You can also delete any log shipping SQL Server Agent jobs created by SQL Server 2000.

Configure Your SQL Server Attack Surface

Security is an exercise in creating enough barriers to the system such that the effort involved to attack a system exceeds the
benefit derived from the data. In order to defeat a variety of attacks systems, rely on a ―defense in depth‖ approach that places
several barriers in the way of an attacker.
During the installation of your instance, you have the option to specify the authentication mode that is allowed. If you limi t access
to an instance to Windows logins only, you can prevent a wide variety of attack methods by ensuring that any user connecting to
your instance must first authenticate to a Windows domain.
Once the instance has been installed, you can configure the network protocols to allow remote connections. If remote connections
have not been enabled, an attacker must first gain access to the machine that your instance is running on. Your configuration for
remote connections and authentication mode represent the first layers of security for your instances.
Each feature within SQL Server enables access to functionality, but at the same time provides a method for an attacker to find a
way into the system. The most significant potential for attacking an instance is through the use of features that expose an external
interface or ad hoc execution capability. When you install a SQL Server instance, any feature that is not necessary for the core
engine to run has been disabled by default.
You can enable or disable features within your instance by executing the system stored procedure sp_configure. Although
sp_configure is used for several internal features, the following list describes how the options apply to the attack surface of your
instance. Unless you are specifically using one of these features, it should be disabled:
Ad Hoc Distributed Queries
Allows a user to execute OPENROWSET and OPENDATASOURCE. Passwords are embedded into the text of the query, exposing a
login and password to an attacker. If you need to frequently access remote data sources, you should use a linked server.

CLR Enabled
The Common Language Runtime (CLR) enables triggers, functions, and stored procedures that have been written in .NET languages
such as C#.NET to execute within your SQL Server engine. If the CLR is disabled, CLR routines are not allowed to run.
Cross Database Ownership Chaining (CDOC)
Allows users to cross databases without having permissions rechecked as long as an ownership chain has not been broken.

Database Mail
Enables the use of the Database Mail features.

External Key Management

Allows approved external key management (EKM) software to manage encryption keys used within your instance.

Filestream Access Level

Enables the FILESTREAM capabilities within your instance. When set to 1, you can use T-SQL to manipulate FILESTREAM data.
When set to 2, you can use a Windows API to directly interact with FILESTREAM data from your application.

OLE Automation Procedures

Allows OLE automation procedures to be executed. You can replace any OLE automation procedure with a CLR procedure that is
more fl exible as well as more stable.

Remote Admin Connections

Enables the ability to remotely connect to the Dedicated Admin Connection (DAC). If remote admin connections are not enabled,
you must fi rst connect to the desktop of the machine your instance is running on before creating a connection to the DAC.

SQL Mail XPs

Enables SQL Mail capability for backward compatibility. All SQL Mail functionality should be replaced with Database Mail.

Xp_cmdshell
Enables the use of xp_cmdshell so that you can execute operating system commands.

Know the Monitoring Tools and Resources Available in SQL

Server 2008
The primary monitoring tools you will use for SQL Server are the Reliability and Performance Monitor and the SQL Server Profiler.
But there are other resources also available for monitoring SQL Server. These include:
Activity Monitor This monitor provides information on current users, processes, and locks, as discussed in ―Managing Server
Activity‖ on page 134. To display Activity Monitor, use the Object Explorer view to access an instance of the Database Engine.
Right-click the Database Engine instance and then select Activity Monitor.
Replication Monitor This monitor provides details on the status of SQL Server replication and allows you to configure replication
alerts. To display Replication Monitor, use the Object Explorer view to access an instance of the Database Engine. Right-click the
Replication node and then select Launch Replication Monitor.
SQL Server logs The information in these event logs allows you to view informational, auditing, warning, and error messages that
can help you troubleshoot SQL Server problems. To access the server logs, use the Object Explorer view to access an instance of
the Database Engine. Expand the server node and the Management node. Under the Management node, expand the SQL Server
Logs node and then double-click the log you want to examine.
Job Activity Monitor This monitor provides details on the status of SQL Server Agent jobs. To display Job Activity Monitor, use the
Object Explorer view to access an instance of the Database Engine. Expand the server node and the SQL Server Agent node, and
then double-click Job Activity Monitor.
SQL Server Agent logs The information in these event logs allows you to view informational, auditing, warning, and error
messages that can help you troubleshoot SQL Server Agent problems. To access agent logs, use the Object Explorer view to access
an instance of the Database Engine. Expand the server node and the SQL Server Agent node. Under the SQL Server Agent node,
expand the Error Logs node and then double-click the log you want to examine.
Note that SQL Server documentation refers to the SQL Server and SQL Server Agent logs as error logs. In their current
implementation, however, the logs are more accurately called event logs, which is the terminology used in this chapter. Similar to
event logs in Microsoft Windows, these logs in SQL Server contain informational and security messages as well as error messages.
Event logs The information in the event logs allows you to troubleshoot systemwide problems, including SQL Server and SQL
Server Agent problems. To access event logs, click Start, click Administrative Tools, and then select Event Viewer.
DBCC statements This set of commands allows you to check SQL Server statistics, to trace activity, and to check database
integrity.
sp_helpdb This stored procedure displays information about databases.
sp_helpindex This stored procedure reports information about indexes on a table or view.
sp_helpserver This stored procedure provides information in SQL Server instances configured for remote access or replication.
sp_monitor This stored procedure shows key SQL Server usage statistics, such as CPU idle time and CPU usage.
sp_spaceused This stored procedure shows an estimate of disk space used by a table, indexed view, or Service Broker queue in
the current database.
sp_who This stored procedure shows a snapshot of current SQL Server users and processes.
sys.dm_tran_locks This dynamic management view shows information about object locks.
Note that the sys.dm_tran_locks view replaces the sp_lock stored procedure.
Use T-SQL to View Database Information
You can use Transact-SQL (T-SQL) to examine database information. In SQL Server Management Studio, access the Query view.
You can do this by right-clicking the name of a server to which you have already connected in the Object Explorer view and then
selecting New Query. Alternatively, you can click New Query on the main toolbar, select Database Engine Query, and then establish
a connection to the Database Engine on a specific server.
After you have accessed the Query view, use the following command, where dbname is the name of the database you want to
examine:
sp_helpdb <dbname>
go
When you view database information in this way, you get an overview of the database as well as a listing of current data and log
files. Here is a summary of the information available when you view database properties using T-SQL. This data is returned in two
different result sets; you will need to scroll down in the Results pane to see the additional result set.

compatibility_level The current compatibility level of the database. The level 90 indicates SQL Server 2008 compatibility.
created The date the database was created.
db_size The total size of the database, including all data and log files.
dbid The unique identifier for the database on the current server.
filegroup The filegroup associated with the database file. Filegroups allow you to group sets of database files together.
fileid The unique identifier for the file in the current database.
filename The full file name and path.
growth The number of megabytes or percent by which the file grows.
maxsize The maximum file size. Unlimited means there is no limit.
name The name of the database or file (without a file extension).
owner The database owner.
size The current size of a file.
status The database status.
usage The way the file is used, such as data only or log only.

Manage SQL Server Services from the Command Line

You can start, stop, and pause SQL Server as you would any other service. On a local system, you can type the necessary
command at a standard command prompt. On a remote system, you can connect to the system remotely and then issue the
necessary command. To manage the default database server instance, use these commands:
NET START MSSQLSERVER Starts SQL Server as a service.
NET STOP MSSQLSERVER Stops SQL Server when running as a service.
NET PAUSE MSSQLSERVER Pauses SQL Server when running as a service.
NET CONTINUE MSSQLSERVER Resumes SQL Server when running as a service.
To manage named instances of SQL Server, use the following commands:
NET START MSSQL$instancename Starts SQL Server as a service, where instancename is the actual name of the database
server instance.
NET STOP MSSQL$instancename Stops SQL Server when running as a service, where instancename is the actual name of the
database server instance.
NET PAUSE MSSQL$instancename Pauses SQL Server when running as a service, where instancename is the actual name of the
database server instance.
NET CONTINUE MSSQL$instancename Resumes SQL Server when running as a service, where instancename is the actual name
of the database server instance.
You can add startup options to the end of net start MSSQLSERVER or net start MSSQL$instancename commands. Use a slash (/)
instead of a hyphen (–) as shown in these examples:
net start MSSQLSERVER /f /m
net start MSSQL$CUSTDATAWAREHOUS /f /m
Real World Instead of referencing MSSQLSERVER or MSSQL$instancename, you also can reference the service by its display
name. For the default instance, you use "SQL Server (MSSQLSERVER)" with net start, net stop, net pause, and net continue. For a
named instance, you use net start "SQL Server (InstanceName)", where InstanceName is the name of the instance, such as net
start "SQL Server (CUSTDATAWAREHOUS)". In both usages, the quotation marks are required as part of the command text.