I know this is the SnapManager for Exchange board but I couldn't think of where else to post this question. It is in regard to SnapManager for SQL.
I just got done reading the Microsoft SQL Server 2005 Relational Engine: Storage Fundamentals for NetApp Storage Systems pdf TR-3696 and thought it was good info. However, after designing my server and working out the volumes and luns I'm perplexed by the following paragraph from the document.
When using SnapManager for SQL Server, a variation of this design can be used. Rather than having the
transaction logs on a completely dedicated LUN, they can instead be placed in the root of the SnapInfo LUN.
This design would then change from having five volumes to having four volumes. This is a good design
because, taking the separate SnapManager for SQL Server schedules described above, SnapInfo would get
backed up each time the logs are backed up.
When I configured my Snapmanager for SQL application and tried to move the application database log file to the LUN housing the snapinfo directory I get the following error: "The Selected LUN for storing the Snapinfo Directory is used for storing a database".
I'm not quite sure the best approach to solving this issue. I have 5 really small databases and I'd like to store the log files on the same Volume/LUN as the Snapinfo for convenience however it seems the only way to do this would be to create volume mount points for each of the database log files and place them in empty folders on the same drive as the snapinfo. That seems to be counter to what is stated above because it increases the management of the storage system. IE. more LUNS... Also, if I do this, then I have to work out the correct size for the root Snapinfo LUN so I can mount my volumes within it.
Does anyone have any suggestions? I hope I haven't been too confusing in what I'm asking.
The SnapInfo folder must at all times be placed in a LUN of its own. There cannot be any other files that can be placed on the LUN or the mount point root directly.
The suggestion in TR-3696 is slightly misworded. What the author meant was that you can create another LUN on the same volume as the SnapInfo LUN and then migrate your databases to that LUN. I will have the mentioned paragraph of TR-3696 fixed to reflect this change. Thank you very much for pointing it out to us.
In your case I would suggest that you create a seperate LUN on the same volume on which the SnapInfo LUN is created. You can then mount it either as a drive letter or as a mount-point on the SQL Server host. This LUN can then be used to store all the 5 small databases.
However, the only caveat here is that the restore will become byte-stream-based because multiple databases share the same volume. Also note that there is a limit of 35 databases that can share a volume (as per Microsoft).
Thanks for the update. I've decided to place the logs with the individual databses since they are low use and not tier 1 applications. I will in the future for all tier 1 databases put a volume for the snapinfo with a separate lun for transaction logs.