Causes of SQL Server cluster installation failures

 Data Execution Prevention (DEP) (control

panel\system\advanced\performance) -- Select Turn on DEP for
Essential Programs Only, since any other setting will cause the
installation to fail.

 Trailing spaces -- Trailing spaces on the NIC names will cause the
installation to fail on the installation of the Database Engine piece with
error number 67.

 Logging into other nodes -- If you or another user are RDPed into a
node other than the one you are installing from, then the installation will
fail.

 Internet Explorer Enhanced Security (control panel\add

remove\system components) -- Often this will interfere with installations.
It's best to leave it turned off to avoid problems.

SQL Server performance issues at 3 a.m.

 Profiler trace shows low CPU/IO consumption, but incredibly long

duration. Typically, it is because of an out-of-date execution
plan. Updating the stats will often eliminate this issue.

 Transactions are timing out, but disk space seems plentiful and it's a
simple insert with just one row. Tracing the activity might reveal that the
transactions are actually timing out while they try to grow the files. If a
database is 100GB or more, having a growth percentage at 10% on a
server under load can cause queries to start timing out. It's best to grow
the databases out at a fixed rate rather than a percentage.

 Profiler trace shows a query timing out with high CPU/IO

consumption. Assuming this is a change of behavior and the query
behaved well before, chances are the indexes need to be
defragmented, the statistics are out of date and/or the proc needs to be
recompiled. Your best bet is to check the index fragmentation and, if
 necessary, re-index. Always try to update the statistics on the table and
after that recompile the proc. If you update the statistics, but don't
recompile the proc, sometimes it doesn't pick up the updated statistics
immediately.

 A stored procedure takes forever to run. But if you paste the logic into
query analyzer and run it directly getting extremely quick results, then
be sure to check the parameters. If all the parameters have a default
value, there is a good chance you're the victim of parameter
sniffing. Basically, parameter sniffing is how Microsoft optimizes the
execution plans of a stored procedure using certain parameters. In order
for it to work correctly, you need at least one parameter on a stored
procedure without any default value.

 The Max Degrees of Parallelism setting determines how many

processors (cores) can be used per query. A setting of 0 indicates that
queries can use all cores to execute. The only problem with this is that a
long-running CPU-intensive operation can easily grab all the processors
and block other users from running. On the flip side, limiting each query
to a small number of processors causes statements such as re-indexing
to take much longer to run and blocks users behind them. So it's a
delicate setting.

 Table variables work excellent with small datasets. However, as the

number of rows in the tables exceeds, the variables tend to cause
lockups on production systems. Also, joins between table variables and
real tables often cause table scans, since they are not indexed. The only
way to index a table variable is to define a primary key constraint on it
that generates an implicit clustered index. I would recommend replacing
them with temporary tables, inserting the data, then applying indexes as
needed that will match the production tables.

Backup and recovery options when there's a problem

 Database in suspect mode -- Choose one of two methods to resolve.

1. Run sp_resetstatus 'dbname', then restart SQL Server.

 2. Run sp_configure, set Show Advanced Options to 1, run
reconfigure, then run sp_configure; set Allow Updates to 1, then run
reconfigure. Finally update the status in sys.databases and restart
SQL Server.

 You can't update sys.databases directly unless you set Allow

Updates to 1. The first option resets a suspect database to normal and
the second option allows you to modify the database setting to anything.
If the database goes back into suspect mode, you have corruption.
Once the database is no longer marked as suspect, run dbcc checkdb
to repair damage.

 Database shrinking – Performing an end task, a lock-up or an

accidental client shut off during this operation will occasionally throw the
database into suspect mode. Don't worry, no corruption has occurred.
Simply reset the status.

 Transaction log full – You have three choices here:

1. Choose to back up the transaction log, thus clearing it.

2. Switch the recovery mode to simple (not desirable in most

cases).

3. Add a new log file on an existing drive.

By far, option 2 is typically the fastest way to get the system back
running. But it's often a poor choice because of the loss of point-in-time
recovery and traceability. In most cases, option 1 is your best bet and is
fairly fast. Running a full backup would have the same effect but would
really delay your ability to get the system back running, since the
transaction log isn't free until the full backup is complete.

Some odd SQL Server issues

 Errors in contains table relating to the use of the and and.

Microsoft's full-text search functions are very picky about the use of
"noise" words and will fail in many cases if they are passed as a search
 string. You can either edit the list of noise words contained on the SQL
Server, then rebuild the catalogs, or you can use sp_configure transform
noise words, 1 to tell SQL Server to ignore noise words that come in as
part of the search criteria.

 Date constants in a multi-region system. When used in applications

that might be deployed with various regional settings, data constants
can be tricky. Declare @dDate datetime, set @dDate = '3/10/08' won't
work for many regions and neither will set @dDate = '2008/03/10'. In
order for your application to work in all regions, you should follow
Microsoft's spec for date constants. The following spec works for all
regions and allows your system to work internationally: set @dDate =
'20080310'. It works for all regions and consists of the four-digit year,
two-digit month and two-digit day.

 Creating a server login, then attempting to map it to a database, and

it fails. Chances are the user already exists in the database and just
needs to be linked to the server login. Run this command within the
problem database: sp_change_users_login 'update_one', 'DBUser',
'ServerLogin'. Typically, the DBUser and the ServerLogin are the same
names, but it's not required.

 "Property owner is not available for database dbname" error when

right-clicking and selecting database properties. This occurs when the
owner of a database is deleted from the system and can be resolved by
altering authorization on database::dbname to NewLogin. DBs should
be created with sa ownership wherever possible to avoid this situation.

 Serialization error when shrinking a log in SQL Server 2005. SQL

Server thinks that some kind of backup is in process and can't shrink a
log file while it is in process. If a backup is not in process, then this error
is usually caused by a backup or a third-party backup tool that crashed.
Running a full backup will reset the serialization and the lob will shrink.

problems that occur while working on the leading edge of SQL Server.
1. Database mirror errors: Establishing a synchronous mirror with no
witness.

Symptoms: While setting up the mirror you receive the error "The mirroring
connection to 'TCP://IMPORTANTMACHINE.TEKMIRAGE.COM:7022' has
timed out for database 'ImportantDB' after 10 seconds without a response.
Check the service and network connections." Then, in the SQL Server logs
you see "Database mirroring connection error 4 'An error occurred while
receiving data: '64(The specified network name is no longer available.)' for
'TCP://IMPORTANTMACHINE.TEKMIRAGE.COM:7022."

Problem: The transactions that need to be restored to the mirror location to

achieve synchronization are too large and take more than 10 seconds to
restore/sync to the mirror location. That causes SQL Server to time-out the
establishment of the mirror and there is no way to change this time-out
value. This problem will occur if a witness is not present and the mirror is
synchronous, not asynchronous.

Resolution: First, you must reset the status of the databases. Run "Alter
database ImportantDB set partner off." At this point, you can apply
transaction logs to the mirror and try again to establish the mirror, which
might work if the transaction log is small enough. Disabling any application
functions or picking a really slow time would help. You can also upgrade
SQL Server to resolve this. CU6/CU7 would fix this issue -- they are builds
3228/3239, respectively. You would need to contact Microsoft directly to
get access to these cumulative updates.

View feedback to this tip

2. Primary filegroup is out of space.

Symptom: You receive this error message: "Primary Filegroup is out of

space."
Problem: Database initial size is set to 3 MB, growth limit is set to 6 GB,
growth rate is 6 GB. Vendor is complaining that they keep running around 3
MB.

Resolution: If the initial size is 3 MB and the growth rate is 6 GB, any
attempt to grow would put the database past the growth limit. I recommend
a smaller growth rate of around 200 MB to 1,000 MB, depending on the
application's required transaction times/load. You could also increase the
growth limit.

3. SQL Server login or AD login cannot log into the server even if their
user has been mapped to the appropriate databases with appropriate
permissions (login failed).

Symptom: Server logins exist, but users are unable to log in.

Problems and resolutions:

1.

1. The default database the user was mapped to was deleted,

thus changing the default database to blank, which effectively
disables the user's login.

2. SQL Server logins are case sensitive. Any variation in case will
cause login failure.

3. AD logins are denied with errors such as "trusted account" has

been denied access. If you do not see a login listed in the error, it
means that the AD account has been locked out.

4. ODBC configuration errors: Users are configuring ODBC

accounts to use SQL Server authentication and then typing in
"Domain\UserName." On the SQL Server side, it appears that an AD
login is failing. In reality, though, the AD login name is just being
passed as a SQL Server login that probably doesn't have access.
 Ensure that users are configuring ODBC to use NT authentication if
you want to use AD accounts.

5. User is denied access to the default database. The default

database listed for the login does not have access rights for that
login, thus causing the login to be denied access to its default
database – effectively locking the login out of the server.

6. For SQL Server logins, "Enforce password policy" checkbox is

turned on, or the SQL Server password could be set to expire. SQL
Server will then enforce general corporation policies on the
password. This option can deny a user's access, since it applies a
corporate policy to it, that is, after x number of days require a
password change, certain number of characters, certain number of
numbers, certain number of symbols, a given length, etc. I haven't
seen one application that will handle SQL Server notification of those
policies, so the applications just report a login failure.

4. SQL Server starts up, but is unable to bring a database online.

Symptom: Database does not come back online after a service restart,

and SQL Server logs say SQL Server is unable to find a given path.

Problem/Resolution: Run "select * from sys.master_files where

database_id = db_id('reportserver')" to determine if the file paths for the
databases really exist. Assuming you can find the files, issue the command
"ALTER DATABASE database_name MODIFY FILE ( NAME =
logical_name , FILENAME = 'new_path/os_file_name')" to reset the file
path and restart the SQL Server service, which will recover the database. If
you can't find the database files, you will be forced to restore.

5. Taking a database offline fails.

Symptom: Attempting to take a database offline fails.

Problem: When users are still logged into the system, attempting to take
the database offline fails.

Resolution: Run sp_who2 and identify all users in the database, killing

their spids. You will also want to disable their logins so they can no longer
access the system. Once that is complete and you verify all users are out
by running sp_who2, then you can reliably take the database offline.

6. Database diagram objects can't be installed.

Symptom: You receive an error such as "Database diagram support

objects cannot be installed because this database does not have a valid
owner."

Problem: The database owner is not set to sa, but is likely set to some
other login.

Resolution: All databases should be owned by sa to prevent issues. Run

the command "ALTER AUTHORIZATION ON DATABASE::dbname TO
sa".

7. Changing object ownership

Symptom/problem: Application installed a proc called

SchemaName.ProcName under a schema other than dbo, and now needs
to be changed.

Resolution: Run "ALTER SCHEMA dbo TRANSFER

SchemaName.ProcName". Basically, this will transfer the object
"SchemaName.ProcName" from its current schema to the dbo schema.

Note: sp_changeobjectowner will still work, but it's depreciated, so don't

expect it to be around for long.