SQL Server with Mr. Denny


September 1, 2009  6:31 PM

SQL Server 2008 Clustering Article in SQL Server Magazine

Denny Cherry Denny Cherry Profile: Denny Cherry

For those of you who haven’t check out this months SQL Server Magazine, the cover article was written by yours truly about Clustering SQL Server 2008 on Windows Server 2008.  This is an updated version of the article I did last December on Clustering SQL Server 2005 on Windows Server 2003.

I hope that you find it handy.  (Subscription is required.)

Denny

August 31, 2009  6:26 PM

Difference between an Index and a Primary Key

Denny Cherry Denny Cherry Profile: Denny Cherry

There seams to be some confusion between what a Primary Key is, and what an Index is and how they are used.

The Primary Key is a logical object. By that I mean that is simply defines a set of properties on one column or a set of columns to require that the columns which make up the primary key are unique and that none of them are null. Because they are unique and not null, these values (or value if your primary key is a single column) can then be used to identify a single row in the table every time. In most if not all database platforms the Primary Key will have an index created on it.

An index on the other hand doesn’t define uniqueness. An index is used to more quickly find rows in the table based on the values which are part of the index. When you create an index within the database, you are creating a physical object which is being saved to disk. Using a table which holds employees as an example:

CREATE TABLE dbo.Employee
 (EmployeeId INT PRIMARY KEY,
 LastName VARCHAR(50),
 FirstName VARCHAR(50),
 DepartmentId INT,
 StartDate DATETIME,
 TermDate DATETIME,
 TermReason INT)

The EmployeeId is the Primary Key for our table as that is what we will use to uniquely identify an employee. If we were to search the table based on the last name the database would need to read the entire table from the disk into memory so that we can find the few employees that have the correct last name. Now if we create an index on the LastName column when we run the same query, the database only needs to load the index from the disk into memory, which will be much quicker, and instead of scanning through the entire table looking for matches, because the values in the index are already sorted the database engine can go to the correct location within the index and find the matching records very quickly.

Hopefully this will help sort out some of the confusion.

Denny


August 26, 2009  3:34 PM

Clearing the Windows page file and its effect on server performance

Denny Cherry Denny Cherry Profile: Denny Cherry

I just published a new article over on SearchSQLServer.com about “Clearing the Windows page file and its effect on server performance“.  In the article I talk about the pros and cons of telling Windows to clear out the page file when the server is rebooted.

Denny


August 26, 2009  12:50 PM

Damn rollback scripts are a pain

Denny Cherry Denny Cherry Profile: Denny Cherry

Writing release scripts for a database is easy.  What ever new objects you want you create you create, and what ever objects you need to change you change.  Piece of cake.  Rollback scripts however are a bit trickier since you need to know what everything should look like after the script is done. Continued »


August 20, 2009  6:34 PM

Adding column to take taking to long? You’re probably assigning a default.

Denny Cherry Denny Cherry Profile: Denny Cherry

When you create a column on a database, and you put that column on the right of the table the column shouldn’t be added almost instantly.  However if you are assigning a default value to the column and setting the column to now allow NULL values the operation will take quite a lot longer.  This is because when the operation happens the SQL Server has to write the values to each table.

If you allow the column to have NULL values then the database doesn’t have to write the values to the column so the operation completes very quickly.

Denny


August 17, 2009  11:33 AM

Learn to use the COPY_ONLY flag for one off backups

Denny Cherry Denny Cherry Profile: Denny Cherry

Taking a full backup when doing major database upgrades is a great idea.  However if you are taking differential backups this one off full backup will break the differential backup chain. Continued »


August 13, 2009  11:21 AM

Auto Close is almost as bad as auto grow

Denny Cherry Denny Cherry Profile: Denny Cherry

In theory the auto close setting is a great idea. Free up resources for other databases to use when all the users are finished with the database.

In practice, its not so great.  If a single user connects and disconnects over and over (like say a single user using your website or even a few users using your website) every time a user connects the database has to be spun up and the data loaded into memory.  When the user disconnects the data is removed from cache, and the connection to the file is closed.  Then when the next user runs a query the file is opened again, and the data is loaded into cache.

This causes the users queries to run slower as the data must be pulled from disk each time instead of pulled from memory.  Plus there’s the time spent spinning up the IO thread, and opening the file.  And as I said last time, more time is bad.  Plane and simple.

Denny


August 10, 2009  11:08 AM

Auto Grow is the bane of my existence

Denny Cherry Denny Cherry Profile: Denny Cherry

OK, that’s not entirely true, but it’s pretty damn close.  The auto grow feature of SQL Server shouldn’t be counted on.  It should be disabled, or at least used on as an emergency basis only.

Having the auto grow setting enabled will cause your database to grow when ever it needs to, not when you want it to.  It will also cause fragmentation on the disk, as the physical database files will end up becoming fragmented as your various database all grow as they need fragmenting the files across the disks.

Look at your databases, and figure out how much they are growing.  You’ll want to preallocate the space to the database so that the database space is allocated all in a single chunk on the disk.  This will allow the disk to more easily load data from the disk into the buffer cache as all the data from a single database will be contiguous on the disks.  If the databases and fragmented because of auto grow then as you are trying to load data from the disk, the disk will need to keep moving from place to place sporadically reading data from the disk which takes more time; and more time is bad.

Denny


August 7, 2009  5:22 PM

Slide Decks from OC SQL Users Group

Denny Cherry Denny Cherry Profile: Denny Cherry

Last night I presented two presentations for the Orange County SQL Server Users Group.  I started with my Virtualization presentation and my Storage for the DBA presentations.  The slide decks can be downloaded from those links.

Denny


August 6, 2009  11:02 AM

What do you mean I can’t access my own database when trying to attach it?

Denny Cherry Denny Cherry Profile: Denny Cherry

When you detach a database from Microsoft SQL (I’m talking SQL Server 2005 and up here) the SQL Server automatically changes the NTFS permissions on the file so that only the user who told the SQL Server to detach the file has access to them.  SQL Server does this to ensure that an unauthorized person isn’t able to access the data files. Continued »


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: