Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Why Is It Complicated? Expand / Collapse
Author
Message
Posted Saturday, October 31, 2009 2:42 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 6:37 PM
Points: 33,189, Visits: 15,329
Comments posted to this topic are about the item Why Is It Complicated?






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #812052
Posted Monday, November 2, 2009 2:52 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 8:16 AM
Points: 295, Visits: 1,011
My best guess, it's not been prioritized to the team or that they have run into some issues they have not been able to solve. It is a good low costing product but it has it's issues, for instance RESEED is still bugged and that is a very basic simple feature, one would think.
Post #812264
Posted Monday, November 2, 2009 3:53 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, August 15, 2014 3:04 AM
Points: 2,728, Visits: 1,116
the fact that it is complicated, keeps us working. SQL Server is too simplistic and gui driven already. I see enough of people with next to nothing of experiences, posting basic questions.

there is room for improvement, but if we always got what we wanted, would we be happy?


--------------------------------------------------------------------------------------
Recommended Articles on How to help us help you and
solve commonly asked questions

Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden
Managing Transaction Logs by Gail Shaw
How to post Performance problems by Gail Shaw
Help, my database is corrupt. Now what? by Gail Shaw
Post #812292
Posted Monday, November 2, 2009 4:52 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 8:16 AM
Points: 295, Visits: 1,011
Silverfox (11/2/2009)

there is room for improvement, but if we always got what we wanted, would we be happy?


I would.
Post #812308
Posted Monday, November 2, 2009 4:57 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 6:47 AM
Points: 1,541, Visits: 8,203
Backups and restores are too complicated. It's as if it has been created that way to make sure DBAs keep control of such areas, but I imagine it is just because there hasn't been an obvious need or demand (in the eyes of Microsoft) to make it simpler.
Many moons ago I worked for a company that had an inordinate number of small customers scattered across the country, all with SS 2000 MSDE installed. I wrote a VB/SQL DMO package that controlled the backups and controlled the restores if required - prompting the users for the correct disks. They had to get a password from us if they thought they needed to restore as it's surprising just how often they'd panic and want to do such a thing for no good reason, but it was as automated as it was sensibly possible to make it.


BrainDonor
Linkedin
Blog Site
Post #812310
Posted Monday, November 2, 2009 5:18 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, August 21, 2014 3:52 PM
Points: 5,988, Visits: 12,923
I don't think it is complicated. SSMS will build up a restore job for you starting from the latest full backup to the latest tran log backup. all the information needed is in the msdb database. you can learn all you need about backup and recovery in a couple of hours if you just take the time to read up about it.

Now, Oracle, that is ridiculously complicated, you need a week long course to learn how to restore an oracle database.


---------------------------------------------------------------------

Post #812315
Posted Monday, November 2, 2009 6:39 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, May 7, 2012 9:23 AM
Points: 304, Visits: 716
I agree with you 100%, and more, this is the most talked about topic amongst our technical staff, associates of mine, and customers as well - That is of course, Microsoft's addiction to taking the most simple of tasks and making them as needlessly complex as possible. If you think SQL Server is bad, try working with Team Foundation Server - its supposed to be a simple system for managing code, and yet Microsoft has once again loaded it down with tons of features no one needs, and endlessly complex interfaces for the most simple of activities.

The reason for this? Simple. Its the key difference between intelligence and common sense. Microsoft has thousands of highly intelligent people working for them, but I doubt there are even 10 MS employees with basic common sense. You can see this in just about all their products. Using MS products is like trying to clean your fingernails with a backhoe - a great powerful tool, completely inappropriate for the job at hand.

There is one glimmer of hope though - after the Vista debacle, MS has shown a small inkling of "getting it" with Windows 7. I hope this small inkling becomes a tidal wave trend and that SQL Server, Visual Studio and all of MS product line starts to reflect more common sense design than "intelligence" design where they load down products simply because they can.


There's no such thing as dumb questions, only poorly thought-out answers...
Post #812343
Posted Monday, November 2, 2009 7:10 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, August 22, 2014 11:04 AM
Points: 442, Visits: 485
Backups, if you are only using them for disaster recovery, have been made fairly easy to manage in SQL Server. The problem, as I see it, is that I don't use them for disaster recovery as much as for development. We have a couple dev boxes that are restored at will by anyone in the department. If we need to check data from a certain time in the past or if we want to test something on recent data we run a restore to a dev box using backups from the production environment.

Here's the problem. The simple GUI interface to perform these restores is based on tables - tables that are only current in the production environment. They aren't available to the dev boxes. That means I need my backup files to be named reliably so I can write a script that knows what files to restore based on whatever criteria I require.

Yes. I could set up log shipping if I were so inclined. I'm not. I've instead taken to writing backup and restore scripts that manage things. I'm using extended properties on my databases to specify which ones get differential and T-Log backups. The scripts I have written are fairly easy to use for the structure I have in place. It would be a different story if I wanted to use partitioned tables (which I'm beginning to consider).

I don't see this as something that can be easily managed by simple GUI tools. There's so many different ways you can store data, backup data, and restore data that it starts to look like something that a DBA should be intimately involved in. It's not needlessly complicated - unlike many MS products (BizTalk /shudder). It is complicated to the point it actually needs to be to provide us with the level of security we want or need.

Take a day or two, or maybe a week, and design your backup/restore strategy to meet the needs of your organization. You'll look like a genius (and rightly so) when things go bad and you have things back up and running quickly by running a single script.
Post #812359
Posted Monday, November 2, 2009 7:50 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, June 7, 2013 8:44 AM
Points: 339, Visits: 642
I don't see this as something that can be easily managed by simple GUI tools. There's so many different ways you can store data, backup data, and restore data that it starts to look like something that a DBA should be intimately involved in. It's not needlessly complicated - unlike many MS products (BizTalk /shudder). It is complicated to the point it actually needs to be to provide us with the level of security we want or need.


I mostly agree with this. There are a lot of situations, most in fact, where DR is not the primary use case for backup/restore. It's really hard to script/gui/wizard all the various restore situations while allowing for outages and disk space shortages and poorly trained users. ("Put that Sept 22 copy of INT customer test data on the DEV box again." "Dude, that should have said Not In." "I don't care about the Test backups. We need the Prod backups to fit on the stupid SAN.")

That said, there are *lots* of smaller, simple, vanilla installations out there that would benefit tremendously from a backup/restore wizard with options for DR and simple point in time restoration. Smaller places can be the most vulnerable when bad things happen, and they're the ones most likely to be doing without a trained DBA.



Are you lost daddy? I asked tenderly.
Shut up he explained.

- Ring Lardner
Post #812377
Posted Monday, November 2, 2009 7:59 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 2:33 PM
Points: 2,844, Visits: 1,153
Are BACKUP and RESTORE really that complicated? Compared to, for example, limitations on recursive common table expressions or all the tricks you can perform with MERGE and OUTPUT? Backup and disaster recovery are arguably the most important part of a DBA's job, so we should expect it to take some effort to master. It may be difficult because the commands are boring, haven't changed much in years, and kind of scary because if you get them wrong it could cost you your job. These commands have so many options because there are so many backup & recovery scenarios, but they separate real DBAs from the .Net developers and recent Access graduates.

The simpler you make it, the larger the population of morons who think they're qualified to do it. If you have a week-old full backup, a day-old diff backup, and a hundred transaction log backups since then, all you have to do is open the Restore task and give it a time and it will figure out all the necessary commands. Unfortunately, that makes some people think they're experts. If they know how to get the GUI to script all the commands, and take credit for writing them, they're wizards.

I've been monitoring a project in development where a "Senior DBA" has done over a dozen backups over the course of a week without realizing they were overwriting the same backup file every time (not even appending it!). They know how to click the GUI buttons, but without any real understanding. Giving this person more pushbutton capability to screw things up scares me.



Post #812379
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse