SQL Server Performance

sqlservr.exe high CPU when copying a file

Discussion in 'Getting Started' started by itsupport, Apr 14, 2010.

  1. itsupport New Member

    We have had some odd behavior over the last couple of days. We are running our SQL 2000 server on Windows 2003 VM Server. We currently backup the main DB (180GB) to the SAN, then use backup exec to backup the backup. This use to work fine, however since 3 days ago everytime Backupexec trys to backup the backup sqlservr.exe jumps to about 80-90% and the network utilisation goes from 0.2% to 20% (as you would expect). When we kill the backup sql cpu drops back to 10-15%. I have also tried to copy the file from the server to eliminate backup exec and the same thing happens. It this an issue with SQL?
  2. satya Moderator

    Welcome to the forums.
    THis will be a general behaviour that your third party tool for backups will occupy most of server resources during the processes.
    Are you performing Backups from SQL Server or trying to perform from BackupExec?
    Were there any changes to hardward or hotfix installation to Windows OS recently?
    What is the physical memory on server?
  3. itsupport New Member

    We are currently running the SQL server in a VMWare enviroment with 4GB memory and 2 CPU's. We were using SQL to backup the 170GB DB to a physical server which has the tape drive attached. The backup was taking 7 hours. To get around this issue we created a 200GB partition on the SQL server and backed it up locally, this dropped the backup to 30minutes. We then use Backup Exec to backup this file directly to tape, which also is no issue. As our tapes go offsite we also keep a copy of the backup on the backup server (physical server), saves time on getting tapes back for restores, this is what is killing the sqlservr.exe cpu, copying the backup from the SAN (SQL Server) to the physical server.
    It looks like we may have found the issue. Symantec Network protection (firewall) suprise, suprise. Due to PCI compliance we have to have firewalls configured on all Servers on the internal network. THis was implememted about the same time as the issues appeared, but it is only happening on the production SQL server and none of the other 12 servers. I will keep digging
  4. satya Moderator

    I believe you have long path to go on that side to see if its cauisng, but as I referred it is always best to configure the backup schedule during low activity period when using third party tools and also avoid the ANTI VIRUS & SPYWARE software check on SQL related directories.

Share This Page