Esoteric : SQL General

SQL Server setup log locations and more

arvindsh — Mon, 22 Dec 2008 14:40:35 GMT

In order to efficiently troubleshoot problems involving failed setup, we need to use the setup logs. Once you know where the log files are located, you can start troubleshooting. What to look for in the log files is a separate topic in itself, but at least if you know where the log files are, then you can attempt to look for logical clues in the files. So, where are these log files located? Here's a summary, listed by product and version. I took some efforts to compile the list of available rollup hotfixes and their relevant KB articles, hopefully that in itself is a very useful thing.

So, I hope the list and the notes below are very useful for you; please feel free to rate the article and provide comments as well!

Product Major Version ¹	Product Level ²	Version post setup ³	Bulletins / KB Articles	Location of setup logs ⁴
SQL Server 2000 (8.0)	RTM	8.00.194	N/A	%WINDIR%\sqlstp.log
	SP4	8.00.2039	888799	%WINDIR%\sqlsp.log
	Post-SP4 GDR security rollup ⁷	8.00.2050	MS08-040; 948110	%WINDIR%\SQL2000-KB948110-v8.00.2050-x86-ENU.log; SQLServerClient_Hotfix_KB948110_*.log
	[Recommended] Post-SP4 QFE security rollup ^8.a	8.00.2273	MS08-040; 948111	%WINDIR%\SQL2000-KB948111-v8.00.2273-x86-ENU.log; SQLServerClient_Hotfix_KB948111_*.log ¹¹
	IA64 versions of the security rollups ¹³	Per respective packages mentioned above		%WINDIR%\Hotfix\Hotfix.log %WINDIR%\Hotfix\SQL64_Hotfix_KBnumber_.log
	Clustered instance ¹⁴	N/A		RTM: %WINDIR%\Sqlclstr.log ⁵; %WINDIR%\sqlstpN.log from both nodes Service Pack only: %WINDIR%\sqlspN.log from both nodes; %WINDIR%\remsetup.log from active node Hotfix only: Relevant hotfix files as described above from both nodes
SQL Server 2005 (9.0)	RTM	9.00.1399	N/A	%ProgramFiles%\Microsoft SQL Server\90\Setup\Bootstrap\LOG\Files
	SP1	9.00.2047	913090	%WINDIR%\Hotfix ¹⁰
	SP2	9.00.3042	921896	%ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix; files will have KB921896 as part of their name.
	Post-SP2 GDR security rollup (engine only)	9.00.3068	MS08-040; 948109	Same as above; files will have KB948109 as part of their name.
	Post-SP2 GDR security rollup (engine + Reporting Services)	9.00.3073	MS08-052; 954606	Same as above; files will have KB954606 as part of their name.
	Post-SP2 QFE security rollup (engine only)	9.00.3233	MS08-040; 948108	Same as above; files will have KB948108 as part of their name.
	Post-SP2 QFE security rollup (engine + Reporting Services)	9.00.3282	MS08-052; 954607	Same as above; files will have KB954607 as part of their name.
	CU #11 for SP2 ⁸	9.00.3301	958735	Same as above; files will have KB958735 as part of their name.
	[Recommended] SP3	9.00.4035	955706	Same as above; files will have KB955706 as part of their name.
	CU #1 for SP3 ⁸	9.00.4207	959195	Same as above; files will have KB959195 as part of their name.
	Clustered instance	N/A		%WINDIR%\tasks\SchedLgU.Txt ⁶; Setup bootstrap will copy all the files from remote node to active node.
SQL Server 2008	RTM	10.0.1600.22	N/A	%ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log ⁹
SQL Server 2008	CU #2	10.00.1779	958186
	Clustered instance	N/A		At the time of writing no special considerations are known.

Notes:

This is just the common name which we all tend to use, the value in brackets is the major version number used by the product itself.
To determine the product level use SELECT SERVERPROPERTY(‘ProductLevel’). However this will not reflect the GDR / QFE hotfix status. It just shows the latest service pack.
To determine the exact SQL Server build number / version, use SELECT SERVERPROPERTY(‘ProductVersion’). (More information about other product levels and version numbers is summarized in this KB article.)
Here %WINDIR% refers to the location where Windows is installed (typically C:\WINDOWS) and %PROGRAMFILES% denotes location of the Program Files folder (typically C:\PROGRAM FILES).
This file is only generated for SQL 2000 clustered instance installation. Service Pack installation will update this file, but subsequent hotfix installers will not update this file.
The SQL Server 2005 RTM and service pack installers will launch the remote node setup program using Task Scheduler service. This log file is used to check if the remote task was actually started or not. Check this file (in addition to the regular setup files) on each node of your SQL failover cluster.
GDR vs. QFE releases can be a confusing topic. Luckily they are explained very well in the following blog links:
- http://blogs.msdn.com/psssql/archive/2007/04/06/post-sql-server-2005-service-pack-2-sp2-fixes-explained.aspx
- http://blogs.msdn.com/sqlreleaseservices/archive/2008/04/27/a-changed-approach-to-service-packs.aspx
In general, note that applying a Cumulative Update should be done only if you are facing specific issues fixed by that update; doing so will take you to the QFE tree and you should apply the appropriate QFE rollup (if and when available.) This note applies to all rollups and Cumulative Updates.
- 8.a However for SQL 2000 SP4, we might recommend being on the QFE tree due to the fact that there will be no further service packs for that product.
There are no separate folders for RTM and hotfix / Service Pack installers. Instead, look at the relevant sub-folder of this folder with the latest time stamp to get to the latest installation files. Historical logs will be maintained in the subfolder with the respective timestamps.
SQL Server 2005 SP1 is unique in the SQL 2005 chain because it stores its logs under the Windows\Hotfix folder. Under that there are subfolders for each component, such as SQL9, SQLTools9 etc.
The exact filename is dependent on the name of the self-extracting package which was executed. The SQL 2000 QFE rollup generates many more log files than the GDR installer. This is expected because the GDR security rollup only contains security fixes. The QFE security rollup contains bug fixes and the requisite security fixes. See this KB article for details.
For what to look for in the log files, consider this topic from SQL Books Online. An additional reference for troubleshooting Windows Installer logs is found here.
The hotfix installer for SQL 2000 IA64 is described in this KB article.
Cluster delta specific instructions only; regular log files still apply.

Windows, SQL Server and Multi-Core / Hyper-Threading

arvindsh — Fri, 19 Dec 2008 10:27:12 GMT

Very often we get asked a question about 'how many processors does my SQL Server 200x Edition really support'. This post hopes to summarize the considerations and actual limits.

SQL Licensing is per socket

First, let's take a look at the Books Online topic 'Maximum Number of Processors Supported by the Editions of SQL Server'. It says: SQL Server is licensed per processor socket, and not per logical CPU basis.

So what does that really mean? Again from the above Books Online topic:

For example, the following is considered a single processor for purposes of this table:

A single-core, hyper-threaded processor with 2 logical CPUs per socket.
A dual-core processor with 2 logical CPUs.
A quad-core processor with 4 logical CPUs.

Windows Licensing is also per socket

Just like SQL Server, Windows Server licensing has been based around sockets. This document summarizes it nicely:

For Microsoft software with processor limits, each processor counts as a single processor regardless of the number of cores and/or threads that the processor contains. For example, Windows Server 2003 R2 Standard Edition can be used on a four-processor system, whether the processors in the system are single-core, hyperthreaded, or multicore.

So, what's in my box?

A natural question for customers is, how to determine what is in my server hardware? Is it socket, or cores, or logical CPUs from HyperThreading?

Option 1: Use Intel's utility

From our KB article on SQL and Hyperthreading, we recommend using Intel's CPUCount utility to distinguish this for IA32 or Intel 64 class CPUs. The utility distinguishes between CPUs (sockets), cores, and logical CPUs (HyperThreading). The current article describing it is here and the sample code is here (both are from the Intel website.) If you build the samples using Visual Studio you can see the output below:

Option 2: Use SysInternals CoreInfo

Mark Russinovich has released CoreInfo which can also dump similar information. The only concern I have is that it uses the term 'physical processor' a little too freely, which can confuse someone. Here is sample output for a 1-socket, 2-core, no HT CPU:

Option 3: Windows Vista / Server 2008

MSInfo32 (a.k.a. System Information program) can be used to distinguish between sockets, cores and logical processors.

Option 4: Third Party Tools

A variety of 3rd party tools can report detailed CPU information, such as number of cores, logical processors and more.

Product Limitations

The Windows 2003 CPU (physical socket) limitations can be drawn from this page and an updated one for Windows 2008 at this page:

Windows Edition	Number of physical sockets supported
Windows Server 2003 / 2008, Standard Edition	4
Windows Server 2003 / 2008, Enterprise Edition	8
Windows Server 2003 / 2008, Datacenter Edition	32 (32-bit) or 64 (64-bit)

SQL Server limitations from Books Online:

SQL Edition	Number of physical sockets supported
SQL Server 2005 / 2008, Express Edition	1
SQL Server 2005 / 2008, Standard Edition	4
SQL Server 2005 / 2008, Enterprise Edition	OS Maximum (as per the table above)
SQL Server 2000, Desktop Engine (MSDE)	2 on currently supported OS editions *
SQL Server 2000, Standard Edition	4 on currently supported OS
SQL Server 2000, Enterprise Edition	Check link below *

* There are specific notes for older unsupported OS platforms such as Windows 98 and NT 4.0 which are described in this SQL 2000 Books Online entry.

Also note that SQL 2000 only introduced HyperThreading awareness in SP3 so that the number of logical processors are handled correctly when it comes to enforcing the licensing limits.

There is a related blog post from our CSS SQL brethren which I would recommend all to read.

Resources from TechEd sessions

arvindsh — Thu, 15 Jun 2006 06:20:00 GMT

Several attendees have asked for the resources section from our presentations at TechEd India. Enjoy!

Blogs
SQLCAT: http://blogs.msdn.com/sqlcat
WINCAT: http://blogs.msdn.com/wincat
Slava Oks’ blog: http://blogs.msdn.com/slavao

Product Feedback
http://lab.msdn.microsoft.com/productfeedback/

External Links:
NUMA FAQ: http://lse.sourceforge.net/numa/faq

Books:
Inside Microsoft SQL Server 2005: Query Processing and Optimization (Volume 3)
The Guru's Guide to SQL Server Architecture and Internals (SQL Server 2000)

SQL Server 2005 – Operations
http://www.microsoft.com/technet/prodtechnol/sql/2005/library/operations.mspx

Whitepapers
Troubleshooting Performance Problems in SQL Server 2005 (http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx)
Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005(http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
Statistics Used by the Query Optimizer in SQL Server 2005 (http://www.microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx)
SQL Server 2000 I/O Basics (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx)

Webcasts
Troubleshooting Performance Problems In SQL Server 2005 (http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032275646&EventCategory=5&culture=en-US&CountryCode=US)
Performance Diagnosis in SQL Server 2005 (http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032275586&EventCategory=5&culture=en-US&CountryCode=US)
Supportability features for SQL Server 2005
(http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032275593&EventCategory=5&culture=en-US&CountryCode=US)

PASS 2005 PSS Service Center Labs
http://www.microsoft.com/downloads/details.aspx?FamilyID=9b8098a7-e75f-462a-b296-e80199c9f323&displaylang=en

Database Snapshots

arvindsh — Wed, 07 Jun 2006 07:18:00 GMT

DB Snapshots are a very useful new feature in SQL Server 2005 Enterprise Edition. They provide us the ability to preserve a consistent picture of the database as it was at a point in time. Both metadata and data are captured in the snapshot.

The main uses of snapshots are for preserving views of the database for reporting purposes, and also to easily recover data affected by user error. Snapshots also provide a means to view the data in the mirror database.

DB Snapshots use "sparse files", which means that the actual snapshot size on disk will be very small initially and would only grow by recording the the changes to the database using a copy-on-write scheme.

Another cool feature of snapshots for recovering from administrative or user error is the ability to revert a database back to a snapshot. This is potentially much quicker than restoring a full backup, as we only copy the changed pages from the snapshot back into the data files. But there are other implications of reverting to a snapshot - most important being the fact that we rebuild the log in such cases. To ensure recoverability of all transactions committed after the snapshot was taken, be sure to backup the log prior to using this feature.