Though it’s true that having fast performing disk (15K rpm or SSD) is good for IO intensiveapplications but in real scenario it’s not enough.
In my 5 years experience with an organizationwhere we had DELL storage of 10 TB with approx 20 disk (600 GB each) of 15K rpm but yet wewere facing alert, PAGEIOLATCH_SH,PAGEIOLATCH_EX & Disk Wait Queue.
The alert was:
“ SQL Server has encountered x occurrence(s) of I/O requests taking longer than 15 seconds to complete on file […..]. The OS file handle is 0x000006A4. The offset of the latest long I/O is: 0x00000 .”Because everything was configured correctly at database end, I connected to IT-Infra and they connected to DELL support and fortunately they found it was firmware issue.
Apart from that we are having best performing disk there are several things that we need to consider when we prepare our database.
Choose storage with proper RAID configuration for each data file. Put you data file on RAID 5 disk for data safety And Transaction Log (T-Log) file on RAID 10 for better write performance Use windows/Domain service account for SQL Server service and grant it “Performance Volume Maintenance Task” on the server. It skip 0 (zero) initialization of your database when you restart SQL Server service. It does not apply for T-Log file as it’s always 0 (zero) initiated on SQL Server. Normally DBAs lefter there database’s data file with auto grow configuration which add an extra work to SQL Serve engine to allocate space on disk at run/write time. So it’s better to keep your data file fixed sized and configure auto grow in MB (fixed growth) instead of percentage (dynamic growth). Good practice is calculate your database growth per month/year and allocate the space to the data file (mdf/ndf) that it will require in next month/year. This is very important part of database configuration is T-Log sizing. Before we go ahead with Transaction Log File size we should know something about it. Transaction Log File consists of multiple VLF (Virtual Log File). It contains active transactions (Not committed) Number and Size of VLF is determined by initial size and auto growth type (dynamic or fixed size) we select when we create database (it can be edited). By default initial size of transaction log file is 1 MB and auto growth in 10%. Now it’s time to configure transaction log file of our database. Before configuring it we should know that having too many and very few VLF in big size impact database performance. So, here is the formula being used to calculate number of VLF according to Transaction Log File size. If you have T-Log with initial size 1MB and auto-growth set to 10% or 1MB, you will have 4 VLF (3 of 248KB and 1 with 272KB) by default. If active transaction exceeds limit of 4 VLV SQL Server adds VLF with 256KB. T-Log with initial size above 1MB and below64MB creates 4 VLF (Initial Size/4). T-Log with initial size above 64MB and below 1GB creates 8 VLF (Initial Size/8). T-Log with initial size above 1GB and below 16GB creates 16 VLF (Initial Size/16). Choose proper recovery model according to RPO & RTO FULL : Writes each & every transaction in transaction log file so number of writes increases on you disk. But this is only the recovery model with support Point-in-Time recovery of you database if something goes wrong. BULK_LOGGED : It record the allocation units that get changed by transaction into transaction log file. So number of writes would be lower as comparison to FULL recovery model. Point to remember is, ” it does not support Point-in-Time Recovery. SIMPLE : It writes every transaction to transaction log file joust like full recovery model. But difference is, “after the transaction is committed, it’s marked as inactive by SQL Server and get over written by next transaction. So, T-Log size grows according to active transaction size. Don’t data files in compressed drives. Exclude SQL Server database file (.mdf, .ndf & .ldf) from Anti Virus scan. Use “Disk Defragmenter” periodically.I hopemy experience will save DBAstime andthey would have good performing database.
Thanks
