Analysis of Opie Oils Databases

2
Analysis of Opie Oils Storefront Database Sqlserver 2005 vs 2008 performance differences Many sites have experienced this. Some suggested solutions involve tweaking system parameters, but in this case I think there are other issues relating back to Sqlserver 2000, which should be resolved first. Hardware differences Sqlserver is IO bound so 2 disks are better than 1 as mutiple io requests can be serviced by the disks simultaneously. I would prefer 3 or 4 for ease of recoverability in the event of a major disk fault : 1 for OS and pagefiles, 2 nd for databases, 3 rd for transaction logs, 4 th for backups and tempdb. There is no sign of high disk queuing in the resource monitor but continuous monitoring over a periosd might reveal a different story. In any case, having everything on 1 disk is risky, despite reliability of modern hardware. If the unthinkable happens, you could be offline for a long time. However, if log shipping to IIS server is implemented, you could be back up and running within minutes on IIS server. Similarly the database server could be used as backup for web server. Solid State disks have come down in price and in any case represent a lower cost per IO than spindles. Database issues Tempdb Tempdb is used as a work area. The application also uses temporary tables, which are stored in Tempdb. A newTempdb is created each time with the initial allocation the Sqlserver instance is restarted. Recommendation: Set initial value to a high enough size to reduce risk of extents eg 200 Mb with extent of 25%. This can be done in database properties but won't take effect until next sqlserver restart. Indexes There are a large number of indexes on some tables e.g. Category, Product, ProductVariant. 87 Nonclustered indexes across the opieoils storefront database are being updated but not used for access, so sqlserver is doing work for no benefit. A further 48 NC indexes have less read accesses than scans, so are of questionable value and need reviewing. This makes 135 out of a total 242 NC indexes, which could potentially be removed with no adverse effects and reduce sqlserver workload. On the product table there are duplicates e.g. 1 index with Published column (tinyint) and another containing published and deleted (tinyint). For each there is a small number of key values with high number of duplicate key values. If this is the case, a table scan would be more efficient than using the index. These columns could be added to another index Howard Perry Page 1 of 2 24/06/13

Transcript of Analysis of Opie Oils Databases

Analysis of Opie Oils Storefront Database

Sqlserver 2005 vs 2008 performance differences

Many sites have experienced this. Some suggested solutions involve tweaking system parameters, but in this case I think there are other issues relating back to Sqlserver 2000, which should be resolved first.

Hardware differences

Sqlserver is IO bound so 2 disks are better than 1 as mutiple io requests can be serviced by the disks simultaneously. I would prefer 3 or 4 for ease of recoverability in the event of a major disk fault :1 for OS and pagefiles, 2nd for databases, 3rd for transaction logs, 4th for backups and tempdb. There is no sign of high disk queuing in the resource monitor but continuous monitoring over a periosd might reveal a different story.

In any case, having everything on 1 disk is risky, despite reliability of modern hardware. If the unthinkable happens, you could be offline for a long time. However, if log shipping to IIS server is implemented, you could be back up and running within minutes on IIS server. Similarly the database server could be used as backup for web server.

Solid State disks have come down in price and in any case represent a lower cost per IO than spindles.

Database issues

Tempdb

Tempdb is used as a work area. The application also uses temporary tables, which are stored in Tempdb. A newTempdb is created each time with the initial allocation the Sqlserver instance is restarted.

Recommendation: Set initial value to a high enough size to reduce risk of extents eg 200 Mb with extent of 25%. This can be done in database properties but won't take effect until next sqlserver restart.

Indexes

There are a large number of indexes on some tables e.g. Category, Product, ProductVariant.

87 Nonclustered indexes across the opieoils storefront database are being updated but not used for access, so sqlserver is doing work for no benefit. A further 48 NC indexes have less read accesses than scans, so are of questionable value and need reviewing. This makes 135 out of a total 242 NC indexes, which could potentially be removed with no adverse effects and reduce sqlserver workload.

On the product table there are duplicates e.g. 1 index with Published column (tinyint) and another containing published and deleted (tinyint). For each there is a small number of key values with high number of duplicate key values. If this is the case, a table scan would be more efficient than using the index. These columns could be added to another index

Howard Perry Page 1 of 2 24/06/13

Analysis of Opie Oils Storefront Database

All indexes, both dta and other need to be reviewed and unnecessary ones removed, as excessive numbers of indexes need updating for row inserts and updates and this can cause locking, which in turn affects selects.

NTEXT

Ntext , text, and image data types have been deprecated since Sqlserver 2005 and will be removed in a future version of SQL Server, according to Microsoft. It's recommended to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead. These newer datatypes offer faster string manipulation/searches.

However, implementation is tricky, so needs to be done offline.

NOLOCK (Table Hint)

The application makes extensive use of the with Nolock hint. This was likely used to overcome excessive locking in Sqlserver 2000. SQL Server 2005 fixed most of the bugs that made nolock necessary, so you shouldn't need it and certainly not on SS 2008, except possibly in rare circumstances.

Microsoft say: “Table hints override the default behavior of the query optimizer for the duration of the data manipulation language (DML) statement by specifying a locking method, one or more indexes, a query-processing operation such as a table scan or index seek, or other options. Table hints are specified in the FROM clause of the DML statement and affect only the table or view referenced in that clause.

Caution

Because the SQL Server query optimizer typically selects the best execution plan for a query, we recommend that hints be used only as a last resort by experienced developers and database administrators.”

Another quote from an article written in 2006

“With the NOLOCK hint (or setting the isolation level of the session to READ UNCOMMITTED) you tell SQL Server that you don't expect consistency, so there are no guarantees. Bear in mind though that "inconsistent data" does not only mean that you might see uncommitted changes that were later rolled back, or data changes in an intermediate state of the transaction. It also means that in a simple query that scans all table/index data SQL Server may lose the scan position, or you might end up getting the same row twice. "

This means that nolock should only be used for reads and and only in exceptional cases. If the data selected is to be used to update the database eg in an order, it needs to be re-read without nolock to ensure the data is consistent.

Howard Perry Page 2 of 2 24/06/13