Data Backup and Recovery
Data Backup and Recovery
Mostly at listing databases. For instance, clone wizard takes about 3 minutes to list the databases available for cloning from existing backup set, and 3 more after I double-click a backup until I can click next, and there's only a dozen databases on the server. The clone process itself takes about 6 minutes, most of it waiting on "Retrieving ONTAP virtual disks information...". The configuration is as follows:
FAS2040 clustered pair running ONTAP 7.3.6
e0a and e0b in single mode vif used for CIFS and NFS
e0c and e0d configured separately and used for iSCSI with MCS
3 hosts running vSphere 4.1 update 1 (ESXi)
2 Windows Server 2008 R2 SP1 guests running MSCS - each guest has a NIC in LAN network, CIFS network, heartbeat network, iSCSI1 network (accesses e0c on both heads) and iSCSI2 network (same for e0d)
Microsoft iSCSI initiator configured to access LUNs on both filer heads using 2 NICs in MCS
Clustered instance of SQL 2008 10.0.4064
SnapManager for SQL 22.214.171.1246
7 databases have "private" LUNs (data LUN on one filer, log LUN on the other, one DB per LUN pair), others sit in a common userdb data + log LUN pair, system databases on a separate LUN, tempdb on a separate LUN, snapinfo on a separate LUN, all the LUNs are using mount points
DNS resolution is instant and correct, storage system preferred IPs are set in snapdrive, snapdrive actions themselves are reasonably quick (not instant, but no more than 3-5 seconds).
Note that the process doesn't fail, and doesn't even produce any error or warning messages - it just takes an uncomfortably long time to progress and finish.
Google turned up this thread http://communities.netapp.com/thread/15761 which is similar (only worse), but 2 years old and still not answered.
Hi Boris ,
Can you share the relevant smsql and sdw logs with me ?
Which exact log files do you need?
Hi Boris ,
Can you please upgrade to SnapManager - 5.1P2 and upgrade to version 126.96.36.1999 ? There will be lazyload implementation for enhanced wizard performance in the next release and you will observe database enumeration to happen quickly.
We are having the same type of issue with SnapManager timing out while trying to enumerate a database.
Did the Lazy enumeration feature get released?
How do we use it?
The lazyload implementation is already in 5.2.Which particular wizard are you facing issue with ? Is it in the backup wizard during database enumeration ?Also tell me the version of SDW that you are using .
Yes. We are finding the backup wizard slow during database enumeration.
We are using snapmanager 5.2.
What is lazyload?
Have you tried disabling antivirus and firewall software on the windows SQL server host, to see if it makes a difference?
I believe snapmanager communicates with the filer using http over port 80. We saw cases where our AV software was interfering and we had to add an exclusion for the netapp software processes.
Innovative NetApp® technologies enable organizations to extract greater benefits out of their MicrosoftSQL Server® deployments in the area of backup management of SQL Server deployments. The varioustechnologies empower the database administrator to design a robust backup management strategy toprotect the organization’s SQL Server resources.NetApp provides industry-leading solutions in the areas of complete data protection; thin storageprovisioning; data de-duplication; file-based backups and instantaneous SQL Server database backupsand restores.The intent of this document is to discuss the best practices that empower the user to maximize thebenefits from using SnapManager for SQL Server (SMSQL)..
*Good FRIENDS are hard to find, harder to leave, and impossible to forget*
I am having this issue with SMSQL 5.2 (slow wizards). Does anyone know anything about this issue in version 5.2? Is there a patched release?
I am having the same issue with SMSQL 5.2. Seems to happen on one of our large data warehouses. This database has over 14,000 files.
My problem was related to having the data and management ports on the same network. After they were separated, the slowness was gone (and it was a general behavior, not only for a specific database).