Using Volume Snapshots with Microsoft SQL ServerMicrosoft
SQL Serveris a relational database management system developed, distributed,and supported by Microsoft Corporation. From SQL Server 2017+additional platforms other than Microsoft Windows are supported,including Red Hat Enterprise Linux,SUSE Linux Enterprise Server,Ubuntu,and Docker Engine.
FlashArray volume snapshots can be used for several use cases with Microsoft SQL Server. These use cases can be orchestrated via:
•Manually using the FlashArray web or command line interfaces
•Automated programmatically using the PowerShell SDK, Python Rest Client,or Ansible Collections
•Integrating into Microsoft SQL Server Management Studio(SSMS)using the FlashArray Management Extension
Data Protection
Volume snapshots of SQL Server databases can be created using one of two methods: application consistency (known as a volume shadow copy snapshot) or crash consistency. Application consistent volume snapshots can be created using the SSMS FlashArray Management Extension, which ensures that the snapshot is captured alongside any operations required to make the snapshot consistent with the application at any one point in time and allow for the database to achieve transaction level point-in-time restore with SQL Server native backups. Crash consistent volume snapshots work independently from an application and will always present a valid database(s) from the point in time of the snapshot but with a lower recovery point objective. The choice of consistency is reliant on the granularity level of restoring a database; application consistency provides point-in-time while crash consistency can achieve recovery point objectives as low the snapshot creation time.
Seeding Always on Availability Groups
Always On availability groups are a feature in SQL Server that provide a replicated environment for a discrete set of user databases. Availability groups can be created to provide high availability or read scale. In either scenario, read scale or high availability, the relevant database needs to have its data copied to the intended instance prior to becoming available. The process of copying data can be done by copying a volume snapshot or protection group to a new volume and attaching it to the system where the intended replica will reside. This process can be performed with crash consistent snapshots with an entire availability group in a single protection group or volume snapshot.
Cloning Databases
SQL Server database copies are made for many reasons, including migration, copying for development and test refresh, reporting databases, and intra-instance ETL scenarios. SQL Server provides several native tooling to perform a transfer of database data to one or more locations. The FlashArray Management Extension can be used in place of native tooling to orchestrate database cloning and copy operations where point-in-time recovery is required. Crash consistent volume snapshots are appropriate for use when point-in-time recovery for cloning is not required.
Using Volume Snapshots with Oracle Database
Oracle Database is a multi-model database management system developed, distributed, and supported by Oracle Corporation. Oracle databases are supported on a range of platforms including HP-UX, Linux, Oracle Solaris, IBM AIX, and Microsoft Windows.
FlashArray volume snapshots can be used for several use cases with Oracle Database. These use cases can be
orchestrated via:
• Manually using the FlashArray web or command line interfaces
• Automated programmatically using the PowerShell SDK, Python Rest Client, or Ansible Collections
Data Protection
Volume snapshots for Oracle Database can be application consistent or crash consistent. Application consistency can beachieved by placing the database in backup mode. Crash consistency is achieved using storage snapshot optimization. And when restored, instance recovery is performed as if it were recovering from a power failure. Volume snapshots by themselves do not constitute a complete data protection strategy as snapshots do not include te journaling capabilities present in Oracle Recovery Manager (RMAN) to roll the database forward to a specific recovery point. Volume snapshots therefore complement—rather than replace—RMAN backup strategies.
Cloning and Refresh
Oracle database copies are made for several reasons, including migration or copying for development and test scenarios. Volume snapshots can be used to clone or refresh a database to one or more targets. In scenarios where databases need to be cloned or refreshed periodically, volume snapshots are an efficient method of eliminating time cost and achieving storage consumption space savings.
Native methods of copying Oracle Databases use RMAN to backup and restore to a different system or using Oracle Data Pump to export data from one system into another. While volume Snapshots must include the entire instance and thus will contain everything like container databases and pluggable databases, the creation of and recovery from a volume snapshot will be faster and more efficient than using RMAN or Oracle Data pump. If only specific tables or an individual data file needs to be restored, RMAN or Oracle Data Pump could be a more appropriate tool to utilize.
Create Physical Standby (Data Guard) Database
Oracle Data Guard implements a physical standby database to ensure production databases survive disasters and data corruption. An Oracle Data Guard configuration can contain a primary database and up to thirty destination systems (standby databases). Typically, database administrators take an RMAN backup of the primary database and restore it to the destination system. Instead, volume snapshots can be used to create a physical standby database using a snapshot of the database volumes on the primary and copying them to new volumes to be attached to the destination system.
Local view: