Datasheet

Industry Trends
We’ll get into the SQL Server 2005 features momentarily, but you’ll notice a trend as you begin to see the
list. Feature after feature will require that a DBA become acclimated to a .NET programming language
such as C# or VB.NET to remain effective. For example, if you are a DBA trying to debug a performance
problem with a CLR stored procedure, you’re going to need to know the language the stored procedure
is written in to understand the performance problem. Features like Integration Services and Reporting
Services are very much tied to expressions, which are variants of VB.NET.
Each new release of SQL Server since 7.0 has required DBAs to know more things that were traditional
concerns of developers only, such as XML. With SQL Server 2005, though, there is a leap forward in the
knowledge a DBA must have to be effective. Essentially, if you don’t know a .NET programming lan-
guage, you may be stuck as a Production DBA indefinitely. There are still roles for Production DBAs, but
even in such roles, you may be less effective.
SQL Server Architecture
In older editions of SQL Server, you had to use many different tools depending on the function you were
trying to perform. In SQL Server 2005, the challenge for Microsoft was to avoid increasing the number of
management tools while increasing the features and products that ship with SQL Server. They accom-
plished this by creating one tool for business-intelligence development and another for management of
the entire platform, including business intelligence and the database engine. Both of these tools are
based on a lightweight version of Visual Studio 2005.
SQL Server envelops a large surface now. It can act as a reporting tool and store your OLAP cubes. It can
also perform your ETL services through SQL Server Integration Services. Most people just use SQL
Server for its classic use to just store data. SQL Server 2005 can run on Windows XP, 2000, Vista, and
Windows Server 2000 and 2003. Tools such as SharePoint and Office quickly integrate on top of SQL
Server and can provide an easy user interface (UI) for SQL Server data. This book covers administration
on each of these tiers.
Transaction Log and Database Files
The relational database has experienced a number of enhancements in SQL Server 2005 to make it more
robust and scalable. As you make changes to a database in SQL Server, the record is first written to the
transaction log. Then, at given checkpoints, it is quickly transferred to the data file. This may be why
you see your transaction log grow significantly in the middle of a long-running transaction even if your
recovery model is set to simple. (We cover this in much more detail in Chapter 18.)
When you first start SQL Server after a stop, it performs a recovery process on each database. This pro-
cess reads the transaction log for any transaction written to the transaction log but never sent to the data
file and rolls it forward onto the data file. Also, any transaction that has not completed will be rolled
back. In SQL Server 2005 Enterprise Edition, this process can be done in parallel across all the databases
on your instance. Additionally, a fast recovery feature in Enterprise Edition makes databases available
after the roll-forward process is complete.
4
Chapter 1
04_055200 ch01.qxp 10/31/06 12:37 PM Page 4