I'm trying to do a Snapshot using Snap Manager for SQL on SQL 2005 IA64, we have 7 database spread to multiple disks with its drive letter (16 LUN), all LUNs are on NetAPP LUN (V-3160).
But when I start the snap manager for sql console, it shows that some of my Databases stated (Invalid/Local Drive ....), but all the drives are on NetAPP LUNs, why the snap manager didn't see that the database files are on netapp lun ?
Thanks in advanced.
Welcome to the forum.
Try running through the SMSQL configuration wizard again and fix any issues it highlights. ie Move databases to NetApp managed storage
Hope this helps
Thank you for your suggestions, I've tried to re-configured de SMSQL configuration wizard, but when I've finished configured 1st database, the drive letter I've been used no longer appear on th right pane of the console and it cannot be used for my 2nd and 3rd database. (I have 5 databases using the same LUN).
My databases (5 DB) have multiple files across 7 drives (LUNs) and almost all the LUNs used by these 5 databases.
I Think I got stuck of SMSQL filegroups limitations, 2 of my databases have more then 15 filegroups, while SMSQL only allow 10 filegroups, may be this is the issue ?
Thank you for your response. Previously the data were stored in HDS storage, I've just migrated the data into V-Series, in the migration prosess the LUN are all created from the filler, not from the host (using SD).
Regarding of the LUNs that was not created by SD, I have attached 1 database to the host using some of the LUNs used by my other 5 database (which not recognize by SMSQL), and the database is recognized by SMSQL, and it can be backup/restore using SMSQL, in this sample I believe the problem is not in the LUNs, but in the database configuration, especially in filegroups configuration. I suspect that this is the issue where SMSQL only support max 10 filegroups, while some of my DB use more than 20 file groups. But again there is a doubt also, because from my 5 DB only 2 that have more then 20 filegroups, while the rest of the 3 are only have max 7 filegroups, but these 3 databases also not recognize by SMSQL to be backup/restore.
So temporarly I used SD Snapshot to snapshot all the LUNs after I stop the sql service first, and mounted from other server to automate flexcone the LUNs so the database can be attached to other host and can be read for MIS process.
The reason for this error is that SMSQL does not allow databases to be spread across multiple LUNs that are also shared by other databases. In your case that is the scenario I believe and not the filegroups limitation. The filegroups limitation is a soft limit and not a hard one. Please refer the Installation & Admin Guide for SMSQL for more details.
Thank you for your response.
I have discusss with DBA team, it seems we can do data file migration, and we will redesign the file and disk allocation for the process, and we will see again the SMSQL functions afterwards.
Thank you again for the response.
I am having the same problem.
I think the resolution is adressed in this KB article:
I let you know if this is the case
Notice that i did not do a upgrade, but there might be a database placed in the wrong folder.
SnapManager for SQL reports Invalid Configuration after upgrading to SQL Server 2005
|After upgrading to, or installing a new instance of Microsoft SQL Server 2005 on an existing host that is running Microsoft SQL Server 2000, SnapManager for SQL may report an invalid configuration. In addition, the database selection will not be available for backup and the Configuration Wizard will not allow changes.|
|SnapManager for SQL reports Invalid Configuration after upgrading to SQL Server 2005.|
Cause of this problem
|Microsoft SQL Server 2005 does not allow databases to reside in the same drive, physical or LUN, as the SQL Server install files or error logs. While the program files are easy to identify, the error logs are not so obvious and will cause the drive to be marked as 'SQL Root'.|
To resolve this problem, follow these steps:
Performance and disaster recovery factors should be considered when deciding on the configuration of SQL Server and SnapManager backup/restore strategies.
LUNs or databases are listed as local/invalid when configuring SMSQL
|LUNs or databases are listed as local/invalid when configuring SMSQL|
Cause of this problem
|This can occur when a new database is created with files on a LUN that is used by another database in a dissimilar configuration.|
This can also occur when database is on a local drive or the database on a LUN has an associated file on a local drive and cannot be backed up by SMSQL.
A single database on a LUN with a log, index file, or other file on a local drive will cause the entire LUN to show as local/invalid because it cannot be properly backed up.
Databases containing multiple .MDB files in different LUNs will cause this error as all files need to be in the same LUN for a consistent backup of the Database.
we ran into a similar issue.
All our databases on one LUN were reported to be on an invalid LUN.
The root problem was that, due to space limitations on the original drive, we shifted the windows page file to the LUN that held most of our databases.
After changing this, the problem disappeared.
Date Posted: 24-JUN-2009
SnapManager 5.0R1P2 for Microsoft SQL Server Based on SnapManager 5.0R1 for Microsoft SQL Server Bugs fixed in this release: 5.0R1P2 ========== 366120 – Restore of Single Database on Single LUN fails for transactional log backup 341035 – SMSQL 5.0 does not work with SQL Server 2008 when full text catalog is enabled 352356 - 5.0 does not set default snapinfo snapshot retention correctly causing volume out of space 352690 - SMSQL V 5.0 "Unable to get valid backup time from snapinfo snapshot name" 359236 - Point in time restore puts database in restoring state 355297 - SMMOSS Restore issue: SMSQL fails to restore data in multiple databases in one LUN in Japanese environment Release Notes: 363584 - SMSQL cannot create scheduled jobs on Windows 2008 Japanese OS. Customers running SQL Server 2005 version 2005.90.3042 or below will not be able to create schedule jobs to backup their SQL databases using SMSQL. Customers must upgrade their SQL Server 2005 service pack level to 3 (SQL version 2005.90.4035). SQL Server 2005 service pack levels and version information SQL Server 2005 RTM 2005.90.1399 SQL Server 2005 Service Pack 1 2005.90.2047 SQL Server 2005 Service Pack 2 2005.90.3042 SQL Server 2005 Service Pack 3 2005.90.4035