SnapManager for Microsoft SQL Server. December 2016 SL10311 Version 1.6.0

Transcription

1 SnapManager for Microsoft SQL Server December 2016 SL10311 Version 1.6.0

2 TABLE OF CONTENTS 1 Introduction Why SnapManager for SQL? Prerequisites Lab Environment Lab Activities Perform a backup with SMSQL Delete a Database and Restore it from a Backup Copy Delete a Table and Restore it from a Backup Copy Configure Consistently Available Shares Migrate a local database to a CIFS share with SMSQL Configuration Wizard Clone a database from Production to Dev with SMSQL Clone a Clone Database from Dev to Dev using SMSQL Clone a Cloned Database from Dev to QA using SMSQL References Version History

3 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

4 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 R DEMO\Administrator Netapp1! SQL1 Windows Server 2012 R DEMO\Administrator Netapp1! SQL2 Windows Server 2012 R DEMO\Administrator Netapp1! SQL-QA Windows Server 2012 R DEMO\Administrator Netapp1! SQL-DEV Windows Server 2012 R DEMO\Administrator Netapp1! DC1 Active Directory Server Win2k8R DEMO\Administrator Netapp1! SVM1 Storage Virtual Machine primary vsadmin Netapp1! SVM2 Storage Virtual Machine vsadmin Netapp1!

5 Hostname Description IP Address(es) Username Password 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 admin Netapp1! cluster clustered Data ONTAP node admin Netapp1! cluster clustered Data ONTAP node admin Netapp1!

6 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 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

7 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 Figure 3-4: 7. Click Next. 7

8 7 Figure 3-5: 8. Select SQL1. 9. Click Next. 8

9 8 9 Figure 3-6: 10. Click Next. 9

10 10 Figure 3-7: 11. Click Next. 10

11 11 Figure 3-8: 12. Click Next. 11

12 12 Figure 3-9: 13. Click Next. 12

13 13 Figure 3-10: 14. Click Next. 13

14 14 Figure 3-11: 15. Click Next. 14

15 15 Figure 3-12: 16. Click Next. 15

16 16 Figure 3-13: 17. Select Yes, or No (Yes will increase backup time). 18. Click Next. 16

17 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

18 Figure 3-15: 22. Click Next. 18

19 22 Figure 3-16: 23. Click Next. 19

20 23 Figure 3-17: 24. Click Finish. 20

21 24 Figure 3-18: 25. Click Start Now and review tasks. 26. Click the Backup Report tab. 21

22 26 25 Figure 3-19: 27. Review scrolling event log. 28. Return to the Backup Task List. 22

23 28 27 Figure 3-20: 29. Click OK. 30. Click Close. 23

24 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

25 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 AdventureWorks Navigate to Tasks > Select Detach. 25

26 5 6 Figure 3-26: 7. Click OK. 26

27 7 Figure 3-27: 8. Observe that the AdventureWorks2014 database is no longer attached. 27

28 Figure 3-28: 9. Click the Windows Explorer icon. 9 Figure 3-29: Click Local Disk (C:\). Navigate to C:\MSSQL\Data\ Right-click the AdventureWorks2012_Data.mdf file. Select Delete.

29 Figure 3-30: 14. Navigate to C:\MSSQL\Log\ 15. Right-click the AdventureWorks2012_log.ldf file. 16. Select Delete. 29

30 Figure 3-31: 17. From the desktop of SQL1, right-click the Recycle Bin. 18. Select Empty Recycle Bin Figure 3-32: 19. Click Yes. 30

31 19 Figure 3-33: 20. Maximize, or re-launch SMSQL. 21. Navigate to the Restore options for SQL Click Restore Wizard from the Actions Menu to the right Figure 3-34: 23. Click Next. 31

32 23 Figure 3-35: 24. Click Next. 32

33 24 Figure 3-36: 25. Double-click on one of the backups. 26. Observe that the backup is listed. 27. Click Next. 33

34 Figure 3-37: 28. Press Next. 34

35 28 Figure 3-38: 29. Click Next. 35

36 29 Figure 3-39: 30. Click Next. 36

37 30 Figure 3-40: 31. Click Next. 37

38 31 Figure 3-41: 32. Click Next. 38

39 32 Figure 3-42: 33. Click Next. 39

40 33 Figure 3-43: 34. Click Yes. 34 Figure 3-44: 35. Click Next. 40

41 35 Figure 3-45: 36. Click Next. 41

42 36 Figure 3-46: 37. Click Finish. 42

43 37 Figure 3-47: 38. Press Start Now. 39. Click the Restore Report tab. 43

44 39 38 Figure 3-48: 40. Observe the restore progress. 41. Click the Restore Task List tab. 44

45 41 40 Figure 3-49: 42. Click OK. 43. Click Close. 45

46 42 43 Figure 3-50: 44. In Microsoft SQL Server 2014 Management Studio, click Database. 45. Click the Refresh icon. 46

47 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

48 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

49 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

50 5 6 7 Figure 3-57: 8. Click OK. 9. Confirm the dbo.databaselog is gone. 50

51 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

52 10 11 Figure 3-59: 12. Click Next. 52

53 12 Figure 3-60: 13. Select Clone Database from existing Backup Set. 14. Click Next. 53

54 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

55 Figure 3-62: 18. Click Next. 55

56 18 Figure 3-63: 19. Click Next. 56

57 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

58 20 21 Figure 3-65: 22. Click Next. 58

59 22 Figure 3-66: 23. Click Next. 59

60 23 Figure 3-67: 24. Click Next. 60

61 24 Figure 3-68: 25. Click Next. 61

62 25 Figure 3-69: 26. Click Next. 62

63 26 Figure 3-70: 27. Click Finish. 63

64 27 Figure 3-71: 28. Click Start Now. 29. Click the Clone Report tab to review the event log progress. 64

65 29 28 Figure 3-72: 30. Review the active log window 31. Click Clone Task List to return to the job task list. 65

66 31 30 Figure 3-73: 32. Click OK. 33. Click Close. 66

67 32 33 Figure 3-74: 34. Maximize, or Open SSMS. 35. Click Refresh (assuming SSMS was not closed). 67

68 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

69 38. Confirm the existence of the previously deleted table 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

70 Figure 3-78: 42. Click Next. 70

71 42 Figure 3-79: Select Data source as SQL Server Native Client Select SQL1 as the Server name. Pick the source database as the attached copy from backup. Click Next.

72 Figure 3-80: 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.

73 Figure 3-81: 51. Click Next. 73

74 51 Figure 3-82: 52. Select dbo.databaselog table. 53. Click Next. 74

75 52 53 Figure 3-83: 54. Click Run immediately. 55. Click Next. 75

76 54 55 Figure 3-84: 56. Click Finish. 76

77 56 Figure 3-85: 57. Review the Status of each item as they succeed. 58. Click Close. 77

78 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

79 59 60 Figure 3-87: 61. Return to SMSQL and click Restore under SQL Under the Action menu, Click Clone Wizard. 79

80 61 62 Figure 3-88: 63. Click Next. 80

81 63 Figure 3-89: 64. Select Delete Cloned Database. 65. Click Next. 81

82 64 65 Figure 3-90: 66. Select the attached cloned database backup from earlier. 67. Click Next. 82

83 66 67 Figure 3-91: 68. Click Finish. 83

84 68 Figure 3-92: 69. Click Start Now. 70. Click Delete Clone Report tab to review log. 84

85 70 69 Figure 3-93: 71. Click Delete Clone Task List to return to the task list. 85

86 71 Figure 3-94: 72. Click OK. 73. Click Close. 86

87 72 73 Figure 3-95: 74. Refresh the Databases list attached to SQL1. 87

88 74 Figure 3-96: 75. Confirm the previously attached backup copy is now detached. 75 Figure 3-97: 88

89 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

90 3 Figure 3-100: 4. Enter Username as admin and Password as Netapp1! 5. Click Sign In. 90

91 4 5 Figure 3-101: 6. Navigate to Storage Virtual Machines > svm1 > Storage > Shares. 7. Highlight the sql2_data share. 8. Click Edit. 91

92 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

93 9 10 Figure 3-103: 11. Highlight the sql2_log share. 12. Click Edit. 93

94 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

95 13 14 Figure 3-105: 15. Observe the status of the CA Shares Properties for both shares. 95

96 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 / CIFS Server name / IP of Data LIF: sql-share / 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

97 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

98 3 4 5 Figure 3-109: 6. Confirm the Storage Virtual Machine is displayed. 7. Click Cancel. 98

99 6 7 Figure 3-110: 8. On SQL2, launch Microsoft SQL Server 2014 Management Studio. 9. Click Connect when prompted to connect to SQL Figure 3-111: 10. Right-click the AdventureWorks2014 database. 11. Select Properties. 99

100 10 11 Figure 3-112: 12. Select Files. 13. Scroll window right. 100

101 12 13 Figure 3-113: 14. Observe the local file location of the database and log files. 15. Click Cancel. 101

102 14 15 Figure 3-114: 16. Launch SnapManager for SQL. 17. Click on SQL Click OK to start the Configuration Wizard. 102

103 17 18 Figure 3-115: 19. Click Next. 103

104 19 Figure 3-116: 20. Click Next. 104

105 20 Figure 3-117: 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.

106 Figure 3-118: 25. Highlight the Log File in the Database Selection Pane. 26. Highlight location: \\SQL-SHARE\sql2_log\ 27. Click < = > button. 106

107 Figure 3-119: 28. Click Next. 107

108 28 Figure 3-120: 29. Click Next. 108

109 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

110 Figure 3-122: 33. Click Next. 110

111 33 Figure 3-123: 34. Click Next. 111

112 34 Figure 3-124: 35. Click Next. 112

113 35 Figure 3-125: 36. Click Next. 113

114 36 Figure 3-126: 37. Click Next. 114

115 37 Figure 3-127: 38. Click Finish. 115

116 38 Figure 3-128: 39. Click Start Now. 40. Examine the Configuration Report. 116

117 40 39 Figure 3-129: 41. Observe the live status report, then click on Configuration Task List. 117

118 41 Figure 3-130: 42. Click OK. 43. Click Close. 118

119 42 43 Figure 3-131: 44. Return to SQL Management Studio. 45. Right-click AdventureWorks Select Properties. 119

120 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

121 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

122 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

123 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 AdventureWorks

124 4 Figure 3-139: 5. Click Connect. 5 Figure 3-140: 6. Select Database Engine

125 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

126 8 Figure 3-143: 9. Still on SQL-DEV, open SnapManager for SQL Server. 10. Go to Restore under SQL Find an existing backup under Local Backups. 12. Double click on the backup, and Right-click and launch Clone. 126

127 Figure 3-144: 13. Click the elipses button... next to Clone as Database. 127

128 13 Figure 3-145: 14. In the Restore as Database field enter: AdventureWorks2014_Dev Click OK. 128

129 14 15 Figure 3-146: 16. In the Clone to Server (instance), click the... to change the instance to a new server. 129

130 16 Figure 3-147: 17. Enter SQL-Dev. 18. Click OK. 130

131 17 18 Figure 3-148: 19. Click Clone

132 19 Figure 3-149: 20. Click OK. 132

133 20 Figure 3-150: 21. Click Start Now. 22. Click on the Clone Report tab to monitor the progress. 133

134 22 21 Figure 3-151: 23. Return to Clone Task List. 134

135 23 Figure 3-152: 24. Click OK. 25. Click Close. 135

136 24 25 Figure 3-153: 26. Once complete, return to SQL Server Management Studio and Refresh. 136

137 26 Figure 3-154: 27. Observe AdventureWorks2014_Dev01 under SQL-DEV 137

138 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

139 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

140 5 6 Figure 3-159: 7. Click Next. 140

141 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

142 Figure 3-161: 11. Select the AdventureWorks2014_Dev01 database under the SQL-DEV instance. 12. Click Next. 142

143 11 12 Figure 3-162: 13. The Clone Wizard walks you through the process, click Next. 143

144 13 Figure 3-163: 14. Append the name of the Restore as Database with..._dev Click Next. 144

145 14 15 Figure 3-164: 16. Click Next. 145

146 16 Figure 3-165: 17. Select No, I want to clone databases from an unverified backup. 18. Click Next. 146

147 17 18 Figure 3-166: 19. Click Yes. 19 Figure 3-167: 20. Click Next. 147

148 20 Figure 3-168: 21. Click Next. 148

149 21 Figure 3-169: 22. Click Next. 149

150 22 Figure 3-170: 23. Click Next. 150

151 23 Figure 3-171: 24. Click Next. 151

152 24 Figure 3-172: 25. Click Finish. 152

153 25 Figure 3-173: 26. Click Start Now. 27. Click on the Database Clone Report tab to monitor progress. 153

154 27 26 Figure 3-174: 28. Observe the progress, then Click Database Clone Task List tab. 154

155 28 Figure 3-175: 29. Click OK. 30. Click Close. 155

156 29 30 Figure 3-176: 31. Return to SQL Server Management Studio for the instance SQL-Dev. 32. Click Refresh under Databases. 156

157 32 Figure 3-177: 33. Examine the Clone copy appears. 157

158 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

159 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

160 4 5 Figure 3-182: 6. Click OK. 160

161 6 Figure 3-183: 7. Note that the table is removed from AdventureWorks2014_Dev

162 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

163 Figure 3-185: 12. Click the...button next to Clone as Database. 163

164 12 Figure 3-186: 13. Change the Restore as Database to: AdventureWorks2014_QA. 14. Click OK. 164

165 13 14 Figure 3-187: 15. Change the Clone to Server

166 15 Figure 3-188: 16. Enter SQL-QA. 17. Click OK. 166

167 16 17 Figure 3-189: 18. Click Clone. 167

168 18 Figure 3-190: 19. Click OK. 168

169 19 Figure 3-191: 20. Click Start Now. 21. Click the Clone Report tab to monitor progress. 169

170 21 20 Figure 3-192: 22. Click on the Clone Task List tab. 170

171 22 Figure 3-193: 23. Click OK. 24. Click Close. 171

172 23 24 Figure 3-194: 25. From the SQL Management Studio Press Connect, select Database Engine Figure 3-195: 172

173 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

174 27 28 Figure 3-197: 174

175 4 References The following references were used to write this lab guide 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

176 5 Version History 176 Version Date Document Version History Version September 2015 Initial release Version June 2016 No changes to workflows Version Dec 2016 No changes to guide, match lab images

177 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.