![]() ![]() Admitting your problems is the first step to recovery. I still want to stress to everyone that engineers at NetApp have so far been willing to work with us on the product's weaknesses. Systems that do not change often ie, add or remove user databases. Shops who do not care about using SMSQL on systems already built or who are willing to go through the pains of reconfiguring those systems to use SMSQLĥ. Shops with only a few SQL Servers (<10)Ĥ. Systems which add or remove databases frequently should not use SMSQLġ. Management Console configuration not tightly integrated with SQL Server. Even our storage folks are at their wits end.ģ. ![]() Some of these issue are due to SnapDrive not working well in virtual environment. Random, reoccurring errrors add huge operational overhead and wastes man hours. Management Console too slow when more than 20 servers are registered. Our usage is only on a few servers so, the complexities that you speak of with 50 is not something that we are hitting presently. Recovery can be very quick but you are also looking at different teams to be involved for recovery efforts unless you make your DBA's SAN admins as well. We are using SnapManager for SQL and it does work but does have some weaknesses and IMO some excessive maintenance overhead. As of now though, we are moving a majority of our systems off of SMSQL and back to Idera's SQLSafe. I have to say NetApp has been very receptive and have been honest and aware of the tool's limitations. Īlso, I'll be working directly with NetApp over the next month or so providing them suggestions and real-world examples of the problems we have with the tool and how they can improve it. I will be finishing a blog post this afternoon outlining everything we've learned. The interface is just not made to manage a large number of servers and the random problems the NetApp snap technology has with virtual machines is too much to handle. I can now safely say we've essentially hit the limits of what SMSQL is capable of managing. We currently have about 50 SQL Servers running the software. We implemented SMSQL on a grand scale starting about 8 months ago. I've written a few articles at MSSQLTips concerning implementing SMSQL and also testing backup times with snaps and streaming backups. Business critical dbs should be on their own LUNS, and so should highly transactional dbs, but do you want to become a SAN specialist ? You will if you have to carve out LUNS for each special db on a server with 100 dbs. So now you have to have a backup plan for system db's, and one for user db's, if you didn't split those out before.Ħ) Determining the mix of databases to place on the same LUNs can be very problematic to triage. It will create a job to perform the backups, but we were kind of wanting a way to script this for standardization, and that still eludes us.ĥ) requirement for multiple backup strategies because system db backups are not part of what SM does. Problems we have encountered includeġ) not having enough space to mount the drive allocated Ģ) increased recovery time for a single database when many are assigned to a set of LUNs ģ) occasional SnapManager hiccups that make backups stop working Ĥ) The software backups manage the Log Sequence Numbers (LSNs) so if you take a native backup, you will have to recreate the backups using the SM tool, which is ok but not great. Otherwise, your restore time and complexity INCREASE because the entire contents of the backed-up drive must be mounted, and then searched for the relevant database bits to restore. You should know that this is only true if you plan on restoring ALL of your databases that are assigned to the LUNs that contain the data. ![]() One of the most highly touted benefits of SM is Fast backup and restore. Moving to the new LUNS requires coordination between the storage folks, the server folks, the DBA team, and the user-base to move the files to their new homes. Think of the documentation to maintain and having to find the needed files during an emergency. So if I have 75 DBs on my server, I should have at least 8 luns with database files going to several locations. So my mdf files reside on one LUN, and my ldf's on another, with additional LUNS available for tempdb, and finally backups. NetApp recommends that system database files remain local to the SQL Server physical server, while all other database files are split out on LUNS that are on the NetApp appliance. Where we are in our adoption of this tool is that we have no choice but to convert from backups on local drives or SAN drives (Tivoli) to using this volume backup methodology. This is an awesome tool from a storage tech's point of view. NETApp is very good for what it was designed to do, which is, taking very fast snapshot backups of entire drives. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |