Because of this you should always specify the size of the cache so that you get consistent results from deployment to deployment, especially if you work for a software distributor (ISV, Consulting company, etc.).

Denny

The more exact answer is you typically can’t allocate cache to a specific LUN.  You can usually carve up the total amount of cache into read and write cache.  You want as much write cache as possible so that the database writes directly to the disk as little as possible.

There is no number that I can give saying that you need X amount of write cache for a 500 Gig database, because it doesn’t depend on the database size.  It depends on the amount of data change per minute, how fast the data can be destaged from the write cache to the disks, and how much load is being placed on the disk for reading data.

Denny

In the case of the transaction log, every write into the log is put down to disk immediately, and then written into the database file.  SQL tells Windows to do the write, and Windows tells the disk to do the write.  When the write is written to the write cache the disk tells Windows that the write has been completed, and Windows passes that information to SQL which tells SQL that the write to the log is done, and that it can now write to the database files as well.  If the power fails in the middle of this, after the transaction has been committed to the log, but before it has been committed to the database the data still has been written to the disk.  When the array sees that the power has gone out it’ll write the write cache to the disk, then power down.

When the power comes back up the array will load up the write cache back into memory, and flush the write cache down to where it needs to be written (in the similar way that SQL does a roll forward when it restarts).  Once the writes have been completed the array will allow the hosts (the servers) to see the LUNs and the SQL Server can then fire up and do its normal roll back and roll forward of the data within the transaction log.

Hopefully this helps fix some confusion.

Denny

P.S. Yes I am well aware that I have greatly over simplified the process of how SQL writes to the log and the database, but that isn’t the point of the article.  I’m sure that Paul has some great articles on the internals of how this works over on his blog.

SELECT sys.tables.name TableName,
 sum(a.page_id)*8 AS MemorySpaceKB,
 SUM(sys.allocation_units.data_pages)*8 AS StorageSpaceKB,
 CASE WHEN SUM(sys.allocation_units.data_pages) <> 0 THEN SUM(a.page_id)/CAST(SUM(sys.allocation_units.data_pages) AS NUMERIC(18,2)) END AS 'Percentage Of Object In Memory'
FROM (SELECT database_id, allocation_unit_id, COUNT(page_id) page_id FROM sys.dm_os_buffer_descriptors GROUP BY database_id, allocation_unit_id) a
JOIN sys.allocation_units ON a.allocation_unit_id = sys.allocation_units.allocation_unit_id
JOIN sys.partitions ON (sys.allocation_units.type IN (1,3)
  AND sys.allocation_units.container_id = sys.partitions.hobt_id)
 OR (sys.allocation_units.type = 2 AND sys.allocation_units.container_id = sys.partitions.partition_id)
JOIN sys.tables ON sys.partitions.object_id = sys.tables.object_id
 AND sys.tables.is_ms_shipped = 0
WHERE a.database_id = DB_ID()
GROUP BY sys.tables.name

When you run this code, some of the smaller objects will show more pages in memory than on disk.  It appears that this is normal.  My guess is that SQL Server is preallocating data pages so that if data is added to these pages there is space allocated to them already in order to save time when adding data to the table.

 I’ve removed the system objects from this query, as you can’t do anything to optimize them.

Denny

To determine how much memory your SQL Server database uses for buffer cache and procedure cache, factor in the SQL version you’re using, whether it’s x86, x64 or Itanium and the amount of memory allocated to the SQL Server instance. I talk about how the system configures memory and how it allocates the amount of buffer and procedure cache that’s available.Denny

I started my morning with CLARiiON Rebuild Settings and Data which was an in depth look at how exactly the CLARiiON systems handle rebuilds, and how long various rebuilds take.  In addition we went into detail as to how the CLARiiON will not see that a disk is going to fail, and instead of waiting for it to fail and then having to rebuild it will actually copy the data from the disk ahead of time to a hot-spare then mark the disk as failed so that it can be replaced before the disk actually fails there by providing you with no point in time where your data is unprotected.

 Another session went through the changes to the EMC PowerPath product and all the new features they are building into PowerPath such as the encryption of data when it leaves the server on its way to the disk.

Another session went through some tuning tips an tricks for getting the best performance from the EMC CLARiiON product.  These include the strip size, cache settings at both the LUN and SP level. 

The night ended with the Billy Crystal performance.  I figured that the show would be funny.  I was wrong, it was hilarious.  Like everyone else I’ve seen Billy Crystal on TV and in Movies and thought he was funny, but in person he was probably the best comedy performance that I had ever seen.

Denny

 Starting in SQL Server 2005 you now have the ability to query the system catalog and see what query plans are stored in the cache, as well as the queries which trigger that plan to be used, as well as how many times that cached plan has been used.

The first DMV to look at is sys.dm_exec_cached_plans.  This DMV gives you the size of the plan, the handle of the plan (which is binary), and the number of times the plan has been used.

The next DMV to look at is sys.dm_exec_requests.  This DMV gives you the currently running processes, wait information, all the session settings for the processes, etc.  It also includes the handle for all the plans which are currently being run.  If you join this sys.dm_exec_requests to sys.dm_exec_cached_plans you can see exactly which processes are using which plans.  Because this shows you the spid (the session_id column) and the plan_handle you can see what users are running which commands.

The next object is a system table function called sys.dm_exec_query_plan.  This function accepts a single input parameter of a plan handle.  There are several columns in the output, the most important of which is the query_plan.  This is the actual xml plan which is stored in the SQL Server.

The last object we’ll be looking at is the sys.dm_exec_plan_attributes table function.  This function also accepts a single input parameter of a plan handle.  This function returns the various session settings which were in place when the plan was created.  This is important information to have when working with query plans, as changing a single ANSI connection setting will force SQL to create a new execution plan.

Don’t forget how to view the XML execution plan in the UI.

Denny

Denny

As promised here are the slide decks and sample T/SQL code from the four sessions.  Everything is within a single ZIP file.  I’ve included two copies of each slide deck.  One in the Office 2007 format, and one in the Office 97-2003 format.  They are identical to each other, but I wanted to include both so that people with the older version of Microsoft Office can see the deck without having to download and install the patch which allows Office 2003 to view Office 2007 files.

The sample scripts which I’ve included are all run against the AdventureWorks database or the AdventureWorksDW database (check the USE commands at the top of the scripts).  If they need a different database they will create the new database.

Session 1 – SQL Server Query Tuning (SQL 2000+)

Session 2 – SQL Server 2008 Resource Governor (SQL 2008 CTP5+ only)

Session 3 - SQL Server Service Broker in the Real World (SQL 2005+) (I’ve fixed the problem with the single server script that we were having at the Code Camp.  Turns out I had left the route in place which is why the message never showed up.  The first script didn’t run correctly because I had run the server to server script on my virtual machine and the route was left by accident.)

Session 4 – SQL Server 2008 What’s on the Horizon (SQL 2008 CTP5+)

If you have any questions about these slide decks or sample code feel free to post a comment here, or drop me an email.

Denny

The version of SQL Server that you are running will determine how SQL calculates the maximum size of the procedure cache.

SQL 2000 – 50% of the memory or 1 Gig which ever is lower

SQL 2005 RTM to SP1 – 75% of the first 8 Gigs of RAM + 50% of the next 56 Gigs of RAM + 25% of the ram over 64 Gigs.

SQL 2005 SP2 and up – 75% of the first 4 Gigs of RAM + 10% of the ram over 4 Gigs

As I understand the reason for the change the original settings were causing SQL Server to lockup for some customers as not enough RAM was left over for the buffer cache.

If you are using SQL 2005 in a Win32 platform these calculations change again as the procedure cache must remain within the first 2 Gigs of memory giving you a max of 2 Gigs of procedure cache no matter how much memory you install.

Denny