SnapManager for Microsoft SQL Server December 2016 SL10311 Version 1.6.0
TABLE OF CONTENTS 1 Introduction... 3 1.1 Why SnapManager for SQL?...3 1.2 Prerequisites... 3 2 Lab Environment... 4 3 Lab Activities... 6 3.1 Perform a backup with SMSQL...6 3.2 Delete a Database and Restore it from a Backup Copy... 24 3.3 Delete a Table and Restore it from a Backup Copy...48 3.4 Configure Consistently Available Shares... 89 3.5 Migrate a local database to a CIFS share with SMSQL Configuration Wizard...96 3.6 Clone a database from Production to Dev with SMSQL...122 3.7 Clone a Clone Database from Dev to Dev using SMSQL... 138 3.8 Clone a Cloned Database from Dev to QA using SMSQL... 158 4 References...175 5 Version History... 176 2
1 Introduction This lab introduces the fundamentals of SnapManager for Microsoft SQL with clustered Data ONTAP. You will perform various backup and recovery operations and explore the Data Protection features with SnapMirror and SnapVault that aid in both business continuity and disaster recovery management. You will also explore running SQL on both SAN (iscsi), and NAS (CIFS or SMB3). This lab demonstrates the benefits and how to use the newest release of 7.2. This lab covers basic backup, restore, and clone database functionality. It also demonstrates and highlights the new database clone of clone capability through clone database from Production to QA, and from QA to Dev environment. 1.1 Why SnapManager for SQL? Deploying SQL server on NetApp storage comes with the added enhancement of simplifying management by using the SnapDrive and SnapManager products. SnapManager for SQL (SMSQL) simplifies data management of backups, and helps the database administrator use the benefits of SnapShot technology without having to engage the storage administrator. The solution allows for non-disruptive storage provisioning, and offers a multiprotocol environment. In addition, SMSQL offers the ability to quickly tap into many of the features in clustered Data ONTAP to include data protection features, and to provide the database administrator the required access to reduce duplicate data management efforts. 1.2 Prerequisites This lab introduces SnapManager (and SnapDrive) for Microsoft SQL on NetApp storage running clustered Data ONTAP. A basic understanding of SQL, of SAN, and of NAS fundamentals will help you to execute the lab, but they are not required. Suggested prerequisite labs include the Introductory labs for clustered Data ONTAP. This lab includes steps for mapping shares and mounting LUNs on a Windows client. These steps assume that you have a basic understanding of Microsoft Windows. 3
2 Lab Environment The following illustration provides a diagram of the environment for this lab. Figure 2-1: All of the servers and storage controllers presented in this lab are virtual devices, and the networks that interconnect them are exclusive to just your lab session. While we encourage you to follow the demonstration steps outlined in this lab guide, you are free to deviate from this guide and experiment with other Data ONTAP features that may interest you. The virtual storage controllers (vsims) used in this lab offer nearly all the same functionality as do physical storage controllers (the main exception right now being that these vsims don t offer HA support) but at a reduced performance profile. Table 1: Lab Host Credentials 4 Hostname Description IP Address(es) Username Password JUMPHOST Windows Server 2012 R2 192.168.0.5 DEMO\Administrator Netapp1! SQL1 Windows Server 2012 R2 192.168.0.91 DEMO\Administrator Netapp1! SQL2 Windows Server 2012 R2 192.168.0.92 DEMO\Administrator Netapp1! SQL-QA Windows Server 2012 R2 192.168.0.93 DEMO\Administrator Netapp1! SQL-DEV Windows Server 2012 R2 192.168.0.94 DEMO\Administrator Netapp1! DC1 Active Directory Server Win2k8R2 192.168.0.253 DEMO\Administrator Netapp1! SVM1 Storage Virtual Machine primary 192.168.0.139 vsadmin Netapp1! SVM2 Storage Virtual Machine 192.168.0.149 vsadmin Netapp1!
Hostname Description IP Address(es) Username Password 192.168.0.159 vsadmin Netapp1! SM secondary (SnapMirror) Storage Virtual Machine SV archive (SnapVault) SVM3 The Storage Virtual Machines (a.k.a., vservers) in this lab are designed to provide SAN (iscsi) and NAS (cifs/smb3) protocols environments for each of the SQL servers. All four SQL servers have SnapDrive and SnapManager installed, but only SQL1 is pre-configured. SVM1 has the source volumes for iscsi and CIFS. SVM2 is the SnapMirror Destination for the iscsi volumes on SVM1. SVM3 is the SnapVault Destination for the iscsi volumes on SVM1. Table 2: Lab Controller Credentials Hostname 5 Description IP Address(es) Username Password cluster1 cluster1 mgmt LIF 192.168.0.101 admin Netapp1! cluster1-01 8.3.1 clustered Data ONTAP node 1 192.168.0.111 admin Netapp1! cluster1-02 8.3.1 clustered Data ONTAP node 2 192.168.0.112 admin Netapp1!
3 Lab Activities This lab contains the following activities and tasks: Backup up SQL on NetApp Storage Perform a backup with SMSQL on page 6 Alternate Restore options for SQL on NetApp Storage Delete a Database and Restore it from a Backup Copy on page 24 Delete a Table and Restore it from a Backup Copy on page 48 SQL on NAS (CIFS / SMB3) Configure Consistently Available Shares on page 89 Migrate a local database to a CIFS share with SMSQL Configuration Wizard on page 96 Using the Clone of Clones Features Clone a database from Production to Dev with SMSQL on page 122 Clone a Clone Database from Dev to Dev using SMSQL on page 138 Clone a Cloned Database from Dev to QA using SMSQL on page 158 3.1 Perform a backup with SMSQL 1. Launch the Remote Desktop Connection Manager (RDCMan) link on the jumphost. Figure 3-1: 2. Remote Desktop to sql1.demo.netapp.com using RDC Manager or the RDP Client. 2 Figure 3-2: 3. Click the SnapMananger for Microsoft SQL Server Management Console shortcut on the taskbar. 6
3 Figure 3-3: 4. Expand SnapManager for SQL Server in the left pane. 5. Click SQL1 and wait for SMSQL to connect. 6. Click Backup Wizard. 5 4 6 Figure 3-4: 7. Click Next. 7
7 Figure 3-5: 8. Select SQL1. 9. Click Next. 8
8 9 Figure 3-6: 10. Click Next. 9
10 Figure 3-7: 11. Click Next. 10
11 Figure 3-8: 12. Click Next. 11
12 Figure 3-9: 13. Click Next. 12
13 Figure 3-10: 14. Click Next. 13
14 Figure 3-11: 15. Click Next. 14
15 Figure 3-12: 16. Click Next. 15
16 Figure 3-13: 17. Select Yes, or No (Yes will increase backup time). 18. Click Next. 16
17 18 Figure 3-14: 19. Select Update SnapMirror after operation to update the Business Continuity DP backup. 20. Select Archive backup to Secondary Storage to update DR archive backup. 21. Click Next. 17
19 20 21 Figure 3-15: 22. Click Next. 18
22 Figure 3-16: 23. Click Next. 19
23 Figure 3-17: 24. Click Finish. 20
24 Figure 3-18: 25. Click Start Now and review tasks. 26. Click the Backup Report tab. 21
26 25 Figure 3-19: 27. Review scrolling event log. 28. Return to the Backup Task List. 22
28 27 Figure 3-20: 29. Click OK. 30. Click Close. 23
29 30 Figure 3-21: 3.2 Delete a Database and Restore it from a Backup Copy 1. From the Jumphost launch the Remote Desktop Manager. Figure 3-22: 2. From the Remote Desktop Connection Manager (or standard RDP client), connect to sql1.demo.netapp.com. 24
2 Figure 3-23: 3. From the desktop of SQL1, launch Microsoft SQL Server 2014 Management Studio. 3 Figure 3-24: 4. Click Connect to log into SQL1. 4 Figure 3-25: 5. Right-click AdventureWorks2014. 6. Navigate to Tasks > Select Detach. 25
5 6 Figure 3-26: 7. Click OK. 26
7 Figure 3-27: 8. Observe that the AdventureWorks2014 database is no longer attached. 27
Figure 3-28: 9. Click the Windows Explorer icon. 9 Figure 3-29: 10. 11. 12. 13. 28 Click Local Disk (C:\). Navigate to C:\MSSQL\Data\ Right-click the AdventureWorks2012_Data.mdf file. Select Delete.
11 12 13 10 Figure 3-30: 14. Navigate to C:\MSSQL\Log\ 15. Right-click the AdventureWorks2012_log.ldf file. 16. Select Delete. 29
14 15 16 Figure 3-31: 17. From the desktop of SQL1, right-click the Recycle Bin. 18. Select Empty Recycle Bin. 17 18 Figure 3-32: 19. Click Yes. 30
19 Figure 3-33: 20. Maximize, or re-launch SMSQL. 21. Navigate to the Restore options for SQL1. 22. Click Restore Wizard from the Actions Menu to the right. 21 22 Figure 3-34: 23. Click Next. 31
23 Figure 3-35: 24. Click Next. 32
24 Figure 3-36: 25. Double-click on one of the backups. 26. Observe that the backup is listed. 27. Click Next. 33
25 26 27 Figure 3-37: 28. Press Next. 34
28 Figure 3-38: 29. Click Next. 35
29 Figure 3-39: 30. Click Next. 36
30 Figure 3-40: 31. Click Next. 37
31 Figure 3-41: 32. Click Next. 38
32 Figure 3-42: 33. Click Next. 39
33 Figure 3-43: 34. Click Yes. 34 Figure 3-44: 35. Click Next. 40
35 Figure 3-45: 36. Click Next. 41
36 Figure 3-46: 37. Click Finish. 42
37 Figure 3-47: 38. Press Start Now. 39. Click the Restore Report tab. 43
39 38 Figure 3-48: 40. Observe the restore progress. 41. Click the Restore Task List tab. 44
41 40 Figure 3-49: 42. Click OK. 43. Click Close. 45
42 43 Figure 3-50: 44. In Microsoft SQL Server 2014 Management Studio, click Database. 45. Click the Refresh icon. 46
45 44 Figure 3-51: 46. Expand and observe that the database has been restored and re-attached. 46 Figure 3-52: 47. OPTIONAL: By going to Windows Explorer, you will also see the files have been restored to their original location in C:\MSSQL\. 47
47 Figure 3-53: 3.3 Delete a Table and Restore it from a Backup Copy 1. RDP to sql1.demo.netapp.com. 1 Figure 3-54: 2. Launch Microsoft SQL Server 2014 Management Studio. 48
2 Figure 3-55: 3. Enter SQL1 as the Server Name. 4. Click Connect. 3 4 Figure 3-56: 5. Expand the Tables list under the AdventureWorks2012 database. 6. Right-click the dbo.databaselog table. 7. Select Delete. 49
5 6 7 Figure 3-57: 8. Click OK. 9. Confirm the dbo.databaselog is gone. 50
8 Figure 3-58: 10. Under SMSQL, navigate to Restore. 11. Click Clone Wizard in the Action menu (alternatively, you can double-click on the backup, and click the Clone Option for that backup). 51
10 11 Figure 3-59: 12. Click Next. 52
12 Figure 3-60: 13. Select Clone Database from existing Backup Set. 14. Click Next. 53
13 14 Figure 3-61: 15. Double-click on backup (completed at the beginning of this section). 16. Confirm the backup name shows up in the field below the selection window. 17. Click Next. 54
15 16 17 Figure 3-62: 18. Click Next. 55
18 Figure 3-63: 19. Click Next. 56
19 Figure 3-64: 20. Append the name with _restoredemo, or something similar, as long as it is not the same as the attached database. 21. Click Next. 57
20 21 Figure 3-65: 22. Click Next. 58
22 Figure 3-66: 23. Click Next. 59
23 Figure 3-67: 24. Click Next. 60
24 Figure 3-68: 25. Click Next. 61
25 Figure 3-69: 26. Click Next. 62
26 Figure 3-70: 27. Click Finish. 63
27 Figure 3-71: 28. Click Start Now. 29. Click the Clone Report tab to review the event log progress. 64
29 28 Figure 3-72: 30. Review the active log window 31. Click Clone Task List to return to the job task list. 65
31 30 Figure 3-73: 32. Click OK. 33. Click Close. 66
32 33 Figure 3-74: 34. Maximize, or Open SSMS. 35. Click Refresh (assuming SSMS was not closed). 67
35 Figure 3-75: 36. Observe the database backup copy is connected. 36 Figure 3-76: 37. Navigate to the attached database backup copy. 68
38. Confirm the existence of the previously deleted table. 37 38 Figure 3-77: 39. Right-click on the database with table to import to the original. 40. Go to Tasks. 41. Select Import Data. 69
39 40 41 Figure 3-78: 42. Click Next. 70
42 Figure 3-79: 43. 44. 45. 46. 71 Select Data source as SQL Server Native Client 11.0. Select SQL1 as the Server name. Pick the source database as the attached copy from backup. Click Next.
43 44 45 46 Figure 3-80: 47. 48. 49. 50. 72 Select SQL Server Native Client 11.0 as the Destination. Select SQL1 as the Server name. Pick the destination database as the original database. Click Next.
47 48 49 50 Figure 3-81: 51. Click Next. 73
51 Figure 3-82: 52. Select dbo.databaselog table. 53. Click Next. 74
52 53 Figure 3-83: 54. Click Run immediately. 55. Click Next. 75
54 55 Figure 3-84: 56. Click Finish. 76
56 Figure 3-85: 57. Review the Status of each item as they succeed. 58. Click Close. 77
57 58 Figure 3-86: 59. Refresh and expand Tables under the original database. 60. Find the restored dbo.databaselog table imported from the backup copy. 78
59 60 Figure 3-87: 61. Return to SMSQL and click Restore under SQL1. 62. Under the Action menu, Click Clone Wizard. 79
61 62 Figure 3-88: 63. Click Next. 80
63 Figure 3-89: 64. Select Delete Cloned Database. 65. Click Next. 81
64 65 Figure 3-90: 66. Select the attached cloned database backup from earlier. 67. Click Next. 82
66 67 Figure 3-91: 68. Click Finish. 83
68 Figure 3-92: 69. Click Start Now. 70. Click Delete Clone Report tab to review log. 84
70 69 Figure 3-93: 71. Click Delete Clone Task List to return to the task list. 85
71 Figure 3-94: 72. Click OK. 73. Click Close. 86
72 73 Figure 3-95: 74. Refresh the Databases list attached to SQL1. 87
74 Figure 3-96: 75. Confirm the previously attached backup copy is now detached. 75 Figure 3-97: 88
3.4 Configure Consistently Available Shares 1. From the Jumphost, launch the OnCommand System Manager shortcut. Figure 3-98: 2. Click Advanced. 2 Figure 3-99: 3. Click Proceed to cluster1.demo.netapp.com. 89
3 Figure 3-100: 4. Enter Username as admin and Password as Netapp1! 5. Click Sign In. 90
4 5 Figure 3-101: 6. Navigate to Storage Virtual Machines > svm1 > Storage > Shares. 7. Highlight the sql2_data share. 8. Click Edit. 91
8 6 7 Figure 3-102: 9. Click the checkbox next to Enable continuous availability for Hyper-V and SQL. 10. Click Save and Close. 92
9 10 Figure 3-103: 11. Highlight the sql2_log share. 12. Click Edit. 93
12 11 Figure 3-104: 13. Click the checkbox next to Enable continuous availability for Hyper-V and SQL. 14. Click Save and Close. 94
13 14 Figure 3-105: 15. Observe the status of the CA Shares Properties for both shares. 95
15 Figure 3-106: 3.5 Migrate a local database to a CIFS share with SMSQL Configuration Wizard SUMMARY OF ENVIRONMENT: SVM Management name / IP of LIF: svm1 / 192.168.0.139 CIFS Server name / IP of Data LIF: sql-share / 192.168.0.130 Both above are registered in DNS Caution: if the OCSM Wizard is used to build the SVM (vserver) and/or the CIFS server make sure the data and management LIFs are separate for SQL on CIFS when the CIFS server is built if the name for the CIFS server difffers from the SVM. Also make sure that DNS properly resolves. 1. Using the RDCMan on the Jumphosht, connect to sql2.demo.netapp.com. 96
1 Figure 3-107: 2. Open Computer Management. 2 Figure 3-108: 3. Expand SnapDrive under Storage on SQL2. 4. Select SQL2 (Local). 5. Click Transport Protocol Settings in the Actions Menu, or right-click on SQL2. 97
3 4 5 Figure 3-109: 6. Confirm the Storage Virtual Machine is displayed. 7. Click Cancel. 98
6 7 Figure 3-110: 8. On SQL2, launch Microsoft SQL Server 2014 Management Studio. 9. Click Connect when prompted to connect to SQL2. 8 9 Figure 3-111: 10. Right-click the AdventureWorks2014 database. 11. Select Properties. 99
10 11 Figure 3-112: 12. Select Files. 13. Scroll window right. 100
12 13 Figure 3-113: 14. Observe the local file location of the database and log files. 15. Click Cancel. 101
14 15 Figure 3-114: 16. Launch SnapManager for SQL. 17. Click on SQL2. 18. Click OK to start the Configuration Wizard. 102
17 18 Figure 3-115: 19. Click Next. 103
19 Figure 3-116: 20. Click Next. 104
20 Figure 3-117: 21. 22. 23. 24. 105 In the Database Selection Pane, select disk C under PRIMARY. In the Disk Select Pane, scroll to the right. Highlight the location: \\SQL-SHARE\sql2_data\ Press the < = > button.
23 21 24 22 Figure 3-118: 25. Highlight the Log File in the Database Selection Pane. 26. Highlight location: \\SQL-SHARE\sql2_log\ 27. Click < = > button. 106
26 25 27 Figure 3-119: 28. Click Next. 107
28 Figure 3-120: 29. Click Next. 108
29 Figure 3-121: 30. Scroll the Disk Selection Pane to the right. 31. Highlight location: \\SQL-SHARE\sql2_si\. 32. Click the < = > button. 109
32 31 30 Figure 3-122: 33. Click Next. 110
33 Figure 3-123: 34. Click Next. 111
34 Figure 3-124: 35. Click Next. 112
35 Figure 3-125: 36. Click Next. 113
36 Figure 3-126: 37. Click Next. 114
37 Figure 3-127: 38. Click Finish. 115
38 Figure 3-128: 39. Click Start Now. 40. Examine the Configuration Report. 116
40 39 Figure 3-129: 41. Observe the live status report, then click on Configuration Task List. 117
41 Figure 3-130: 42. Click OK. 43. Click Close. 118
42 43 Figure 3-131: 44. Return to SQL Management Studio. 45. Right-click AdventureWorks2014. 46. Select Properties. 119
45 46 Figure 3-132: 47. Select Files. 48. Ensure that the path of the database and log files are now on the CIFS share. Then click Cancel. 120
47 48 Figure 3-133: 49. Open Windows File Explorer. 50. Enter the path to the CIFS share: \\SQL-SHARE\sql2_data\MSSQL\Data\ 51. Observe that the.mdf file has been copied to the location. 121
50 51 Figure 3-134: 52. Review that the path of the database and log files are now on CIFS share. 52 Figure 3-135: 3.6 Clone a database from Production to Dev with SMSQL Typical database application development life cycle starts with Development to Quality Assurance (QA), to User Acceptance (UAT), then Production. After the code has been deployed to the production environment, developers normally need the exact copy of the production database so that they can diagnose and improve the function and performance of the application. This process can be complicated and time-consuming since it requires storage space and time. Using T-SQL, backup and restore might not be ideal for this task since during the backup process, the production environment will be impacted. SMSQL and SnapMirror provide snapshot backups that have no impact, are fast, and use less space for these tasks. SMSQL empowers users to perform these clones of the Production database simply by using the SMSQL GUI. 122
1. From Jumphost, launch RDCMan. Figure 3-136: 2. Connect to sql-dev.demo.netapp.com. 2 Figure 3-137: 3. Open SQL Server Management Studio. 3 Figure 3-138: 4. Connect to SQL1 and confirm that AdventureWorks2014. 123
4 Figure 3-139: 5. Click Connect. 5 Figure 3-140: 6. Select Database Engine... 124
6 Figure 3-141: 7. Connect to the SQL-Dev server. 7 Figure 3-142: 8. Confirm that the only database is the local one named AW2014DEV. 125
8 Figure 3-143: 9. Still on SQL-DEV, open SnapManager for SQL Server. 10. Go to Restore under SQL1. 11. Find an existing backup under Local Backups. 12. Double click on the backup, and Right-click and launch Clone. 126
10 12 11 Figure 3-144: 13. Click the elipses button... next to Clone as Database. 127
13 Figure 3-145: 14. In the Restore as Database field enter: AdventureWorks2014_Dev01. 15. Click OK. 128
14 15 Figure 3-146: 16. In the Clone to Server (instance), click the... to change the instance to a new server. 129
16 Figure 3-147: 17. Enter SQL-Dev. 18. Click OK. 130
17 18 Figure 3-148: 19. Click Clone... 131
19 Figure 3-149: 20. Click OK. 132
20 Figure 3-150: 21. Click Start Now. 22. Click on the Clone Report tab to monitor the progress. 133
22 21 Figure 3-151: 23. Return to Clone Task List. 134
23 Figure 3-152: 24. Click OK. 25. Click Close. 135
24 25 Figure 3-153: 26. Once complete, return to SQL Server Management Studio and Refresh. 136
26 Figure 3-154: 27. Observe AdventureWorks2014_Dev01 under SQL-DEV 137
27 Figure 3-155: 3.7 Clone a Clone Database from Dev to Dev using SMSQL From time to time the software development life cycle has business requirements that require production copies of a database used for development purposes, which are cleaned before using. For example, an application that has user identifiable privacy type information, like social security numbers or customer sensitive data, may need to be removed from the copies of the prod used in Dev. This can become a time consuming and repetitive task for a database administrator, especially when the adjustments need to be made each time the Production database is copied. Using the Clone of Clone feature, the database anonymization, or cleanup, can occur on the first copy, and then subsequent copies of the cleaned clone can be repeated saving time and effort from the database administration. 1. From the Jumphost, launch RDCMan. 138
Figure 3-156: 2. Connect to sql-dev.demo.netpp.com. 2 Figure 3-157: 3. Open SMSQL. 3 Figure 3-158: 4. Connect to SQL-Dev. 5. Wait for the SQL server to load, and click on the Restore options. 6. Click Clone Wizard. 139
5 6 Figure 3-159: 7. Click Next. 140
7 Figure 3-160: 8. Select Clone Active Production Databases (remember we are on the Dev copy). 9. Add a check next to Run through Clone QuickStart Wizard. 10. Click Next. 141
8 9 10 Figure 3-161: 11. Select the AdventureWorks2014_Dev01 database under the SQL-DEV instance. 12. Click Next. 142
11 12 Figure 3-162: 13. The Clone Wizard walks you through the process, click Next. 143
13 Figure 3-163: 14. Append the name of the Restore as Database with..._dev02 15. Click Next. 144
14 15 Figure 3-164: 16. Click Next. 145
16 Figure 3-165: 17. Select No, I want to clone databases from an unverified backup. 18. Click Next. 146
17 18 Figure 3-166: 19. Click Yes. 19 Figure 3-167: 20. Click Next. 147
20 Figure 3-168: 21. Click Next. 148
21 Figure 3-169: 22. Click Next. 149
22 Figure 3-170: 23. Click Next. 150
23 Figure 3-171: 24. Click Next. 151
24 Figure 3-172: 25. Click Finish. 152
25 Figure 3-173: 26. Click Start Now. 27. Click on the Database Clone Report tab to monitor progress. 153
27 26 Figure 3-174: 28. Observe the progress, then Click Database Clone Task List tab. 154
28 Figure 3-175: 29. Click OK. 30. Click Close. 155
29 30 Figure 3-176: 31. Return to SQL Server Management Studio for the instance SQL-Dev. 32. Click Refresh under Databases. 156
32 Figure 3-177: 33. Examine the Clone copy appears. 157
33 Figure 3-178: Take note of the tables, and the changes made from AdventureWorks2014_Dev01 are not visible. This is a clean development copy from the clone of Production. AdventureWorks2014_Dev02 is now available for another developer to use, or for parallel development testing without having to impact production. 3.8 Clone a Cloned Database from Dev to QA using SMSQL The software development life cycle has specific business requirements that involve promoting builds of a database from one environment to another. For example, changes to a database in Development will need to run through a Quality Assurance testing-effort before the database can be approved for use in Production. In this activity, you will make a change to a cloned database copy in Dev, and clone it to a QA instance from the original snapshot to demonstrate that the clone occurs without impacting the working Dev copy. 1. Launch RDCMan. Figure 3-179: 2. Connect to SQL-DEV. 158
2 Figure 3-180: 3. Launch SQL Server Management Studio. 3 Figure 3-181: 4. Expand tables under AdventureWorks2014_Dev01 under the SQL-Dev instance. 5. Right click on the dbo.errorlog table, select Delete. 159
4 5 Figure 3-182: 6. Click OK. 160
6 Figure 3-183: 7. Note that the table is removed from AdventureWorks2014_Dev01. 161
7 Figure 3-184: 8. Open SMSQL. 9. Click Restore under SQL-Dev 10. Expand AdventureWorks2014_Dev01 under SQL-Dev. 11. Right-click on the snapshot under local backup and select Clone. 162
9 11 10 Figure 3-185: 12. Click the...button next to Clone as Database. 163
12 Figure 3-186: 13. Change the Restore as Database to: AdventureWorks2014_QA. 14. Click OK. 164
13 14 Figure 3-187: 15. Change the Clone to Server... 165
15 Figure 3-188: 16. Enter SQL-QA. 17. Click OK. 166
16 17 Figure 3-189: 18. Click Clone. 167
18 Figure 3-190: 19. Click OK. 168
19 Figure 3-191: 20. Click Start Now. 21. Click the Clone Report tab to monitor progress. 169
21 20 Figure 3-192: 22. Click on the Clone Task List tab. 170
22 Figure 3-193: 23. Click OK. 24. Click Close. 171
23 24 Figure 3-194: 25. From the SQL Management Studio Press Connect, select Database Engine.... 25 Figure 3-195: 172
26. Connect to SQL-QA. 26 Figure 3-196: 27. Expand Databases > AdventureWorks2014_QA. 28. Expand Tables and find the dbo.errorlog table exists 173
27 28 Figure 3-197: 174
4 References The following references were used to write this lab guide. 175 7.0 Documentation TR-4003: MS SQL Server and SnapManager for SQL on Netapp Best Practices Guide TR-4218: SnapDrive 7.0 for Windows SMB 3.0: Best Practices and Deployment Guide TR-4228: SnapDrive 7.0 for Windows for clustered Data ONTAP 8.2 TR-4247: Deploying SQL Server 2012 over SMB3 CA Shares on Clustered Data ONTAP
5 Version History 176 Version Date Document Version History Version 1.4.0 September 2015 Initial release Version 1.5.0 June 2016 No changes to workflows Version 1.6.0 Dec 2016 No changes to guide, match lab images
Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications. NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer s responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document. Go further, faster 2016 NetApp, Inc. All rights reserved. No portions of this presentation may be reproduced without prior written consent of NetApp, Inc. Specifications are subject to change without notice. NetApp and the NetApp logo are registered trademarks of NetApp, Inc. in the United States and/or other countries. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.