HP Storage Mirroring V5 Software - Manual (Page 60)

50 Protecting a SQL Server
NOTE: If Database-Only protection mode is used to protect SQL Server, attempting to attach a replicated
SQL database(s) on the target server after failover can fail when done outside of the Application Manager.
The Storage Mirroring service account (typically the target's LocalSystem account) is the account used to
attach/detach databases on failover/failback. When the database is detached by the failback script, the
Storage Mirroring service account becomes the owner of those files that make up the database (*.mdf, *.ldf,
etc.), and any attempts to manually attach the database may fail if the user account does not yet have NTFS
permissions to access the physical files.
To change the permissions on an individual file, perform these steps on each file that is part of the database's
file list.
1. In Windows Explorer, select the folder that contains the physical files for the database(s) that need to be
manually attached.
2. Right-click, then select Properties .
3. Select the Security tab.
4. Determine if the user account has NTFS permissions for that folder.
5. If the user account does not have specific or inherited permissions, click the Add button.
6. Enter the user account name (such as
domain\administrator
).
7. After the user account has been added, give the account the necessary permissions to the folder ( Full
Control ).
8. Make sure that the subfolders and files are set to inherit these rights, then click OK .
Database only mode, Many-to-One configurations
The following examples describe the SQL many-to-one configurations that can be protected using Storage
Mirroring Application Manager.
Example 1: If you have two SQL servers (
Source1
and
Source2
) where each server has only the default
instance installed, you can protect databases from both servers' default instance, provided that the database
names are unique.
Case1: Both source servers’ default instances have a database named “Accounting”. You can only
protect/failover one server's copy of the database (because SQL on the target will not allow you to attach
more than one copy of the same-named database).
NOTE: If you select and setup both servers’ default instances for protection and both source servers fail, the
“Accounting” database on the first source server to be failed over will be attached. The second server to
failover will not be able to attach its “Accounting” database.
Case2: If
Source1
has a database named “Accounting1”, and
Source2
has a database named
“Accounting2”, then you can protect and failover the database on both servers without any issues.
NOTE: All database filenames (
*.mdf
,
*.ldf
, and
*.ndf
) must either be:
• Uniquely named (for example,
accounting1.mdf
and
accounting2.mdf
), or
• Uniquely located on the target (for example,
c:\Source1\accounting1\accounting.mdf
and
c:\Source2\accounting2\accounting.mdf
).
Example 2: If you have two SQL servers (
Source3
and
Source4
) where each has a named instance installed
(for example,
Source3\instance1
and
Source4\instance2
), you can protect databases from both servers
if the target has at least those two instances installed (
Target1\instance1
and
Target1\instance2
).
Case1: Both source SQL servers have a database named “Accounting”
(
Source3\instance1|Accounting
and
Source4\instance2|Accounting
). You can protect and
failover each SQL server’s copy of the database without any issue.