SQL Server 2005 supports Database Instant File Initialization which skips zeroing out data pages that can reduce the time when performing operations like creating databases, adding files to an existing database, increasing the size of an existing database file manually or thru autogrowth or restoring a database or filegroup. I’ve written an article in MSSQLTips.com highlighting it’s importance both in a disaster recovery and operational performance scenarios. I ran a few tests as well to simply answer a query in the forum regarding the topic. I ran my tests on a VMWare image on a DELL PowerEdge 2650 with 4 X 2.8 GHz CPU and 3GB RAM. The image is running Windows Server 2003 Enterprise Edition with SQL Server 2005 Enterprise Edition as this is an “Enterprise Edition only” feature. I’ve created a 10GB-sized database which took only 0.1 seconds using instant file initialization. Without it, the same took about 2:10 minutes. Imagine doing a restore for a 500GB-sized database. That will save you a lot of time on the restore process. Same goes with file auto growth. The difference in the amount of time it takes to do a restore would definitely matter when you’re dealing with very large databases. Imagine trying to restore a 500GB-sized database. You’ll probably agree after trying it out for yourself
>I was asked by a friend of mine to check why a specific batch file was not being called by a job in Task Scheduler. The first thing I did was to check if the account that was used to run the job had the appropriate permissions. The account used was a domain account with limited privileges. The same account can run jobs on other servers but not on this one. Making it a member of the local Administrators group gave it the permissions to run the job but not as a member of the Power Users group. The former not being an option forced me to check the ACLs on other servers and found out that the account does not have permissions on the CMD.EXE file on my %windir%\system32 folder. After giving the Read and Execute permissions to this account, it was able to run the job using Task Scheduler.
I’ve seen systems where the Everyone group is granted the same permissions on the CMD.EXE file and such is not a recommended practice due to security vulnerabilities. I’ll work on a PowerShell script to check a machine for this and remove the Everyone group, if it exists.