"Dumb" question for all the DBAs...
-
Dumb question... if you are a DBA and I came up to you and said "Here's a physical beastly box... 24 cores, ~140GB of RAM, plenty of flash storage... I need you to set up SQL 2016 on it and migrate this 10TB database from SQL 2008 R2" Assuming of course proper security and best practices, etc. Let's even "complicate" it and assume this 10TB database includes spatial data. How long would it take you? I have ZERO SQL admin experience other then slamming a few SQLs onto local machines or VMs and I think I could realistically get it setup and running in a day or two with plenty of breathing room. Yet, our supposedly experienced DBAs claim its going to take them 3 months!!! LOL... Unbelievable.
I have 2 answers. Either build it yourself, or outsource it. Now, if this was Oracle. I would say he is insane. You could restore that in oracle pretty easily and copy the config settings over pretty quickly. (restoring 10TB of data will take a while). With that said, it always depends. Is it one schema or 200? Do they all talk to each other. When they are done, do they have to sync the stored procedures from a repository? Is it all data or data and code? You have to cut them a little slack. 3 months seems long. Too long. Okay, way too long. I would agree with Days. I might give them a week. But I would certainly consider hiring an outside resource to come in and do it, and also AUDIT your DB guys for best practices. I find a good Audit shakes things up a bit, and puts people on notice. It also brings in a second pair of eyes which can be very helpful, and management gets around the competing groups complaining. Hard to defend the DB guys when the outside guys say they suck! I have done a few IT audits and it is always scary what you find. The great thing is that SOME stuff gets fixed while you are there (like default passwords on wireless routers, OMG). BTW, it looks like you are throwing hardware at your performance problems. Usually a good sign of a design flaw.
-
Dumb question... if you are a DBA and I came up to you and said "Here's a physical beastly box... 24 cores, ~140GB of RAM, plenty of flash storage... I need you to set up SQL 2016 on it and migrate this 10TB database from SQL 2008 R2" Assuming of course proper security and best practices, etc. Let's even "complicate" it and assume this 10TB database includes spatial data. How long would it take you? I have ZERO SQL admin experience other then slamming a few SQLs onto local machines or VMs and I think I could realistically get it setup and running in a day or two with plenty of breathing room. Yet, our supposedly experienced DBAs claim its going to take them 3 months!!! LOL... Unbelievable.
If the install was clean and easy - an hour or so If the DB files could simply be detached, XCOPY'd, and reattached, and if the data could be copied over gigabit ethernet or USB3 or something fast then it's probably a day just to copy the data over, and anything from 5 mins to hours depending on how many physical database files you had. If you were doing a straight upgrade, all security settings were the same (and scripted to allow easy setting up) then add another half hour of faffing around to get that setup (depending on how many databases) But no. Not three months. Unless that's "2 months and 28 days waiting in our TODO queue because we have a ton on our plate, and 2 days to get it done".
cheers Chris Maunder
-
Dumb question... if you are a DBA and I came up to you and said "Here's a physical beastly box... 24 cores, ~140GB of RAM, plenty of flash storage... I need you to set up SQL 2016 on it and migrate this 10TB database from SQL 2008 R2" Assuming of course proper security and best practices, etc. Let's even "complicate" it and assume this 10TB database includes spatial data. How long would it take you? I have ZERO SQL admin experience other then slamming a few SQLs onto local machines or VMs and I think I could realistically get it setup and running in a day or two with plenty of breathing room. Yet, our supposedly experienced DBAs claim its going to take them 3 months!!! LOL... Unbelievable.
-
Yup. That's what they say. That they want to verify everything. These are the same people that write stored procs with spaces in the column names, # signs, etc. We once spent a day tracking down a crash because the SQL dev "accidently" put a trailing space in the column name "ColumnName ". He swore up and down that he didn't change any column names and dev swore up and down that he did. Like I said before, I'm not a SQL expert and database doesn't interest me that much in general, so I'm not up on all the latest & greatest best practices, but I still know you shouldn't put spaces in column names, keep everything consistent, etc. Not have 11 copies of the same data copied all over the place, etc.
-
I feel your pain. I've recently started working on a side project of analyzing our company's database cluster for performance issues. Given this task, the company has no tools to do any kind of DB analysis , so I'm also evaluating tools to do that. During my initial analysis run, I've found that a majority of the problems are coming from bad SQL. Over half are coming from third party products the company has purchased for accounting and so forth. Fixing in-house SQL is one thing, but to get a third party company to fix their cra... um, stuff is a PITA.
It is especially trying when the third party insists that their immaculately-conceived SQL is free from original sin and it must be your loathsome environment which is responsible...
-
It is especially trying when the third party insists that their immaculately-conceived SQL is free from original sin and it must be your loathsome environment which is responsible...
Yup, ran into that last week. I'm having to "build" a case showing how terrible their SQL is, like I was in a court of law. Metrics don't lie especially when they show that the SQL is running for 15 hours at a time. Also, where do they get off writing a SQL statement that starts off Select Top 1 count(*) From ... Good grief! :doh:
-
Dumb question... if you are a DBA and I came up to you and said "Here's a physical beastly box... 24 cores, ~140GB of RAM, plenty of flash storage... I need you to set up SQL 2016 on it and migrate this 10TB database from SQL 2008 R2" Assuming of course proper security and best practices, etc. Let's even "complicate" it and assume this 10TB database includes spatial data. How long would it take you? I have ZERO SQL admin experience other then slamming a few SQLs onto local machines or VMs and I think I could realistically get it setup and running in a day or two with plenty of breathing room. Yet, our supposedly experienced DBAs claim its going to take them 3 months!!! LOL... Unbelievable.
LOL, Spoken as someone who sees it as a simple badge swap. While 2016 is new you can't NEED it - It offers new features that you may want to use, but it also stops functionality that currently exists (deprecated & discontinued features - some real gotcha's moving 2008R2 to 2016.) You also trivialise (or rather don't mention at all) the organisational significance of the database. It this a production system running 24x7 @ 999999. Any DBA can update the "SERVER" in ~30min (with outages), this doesn't mean the database(s) will work on the other side, or that all the attached applications will be able to reconnect and use them. So much has been glossed over with the vision of a new toy to play with...
-
LOL, Spoken as someone who sees it as a simple badge swap. While 2016 is new you can't NEED it - It offers new features that you may want to use, but it also stops functionality that currently exists (deprecated & discontinued features - some real gotcha's moving 2008R2 to 2016.) You also trivialise (or rather don't mention at all) the organisational significance of the database. It this a production system running 24x7 @ 999999. Any DBA can update the "SERVER" in ~30min (with outages), this doesn't mean the database(s) will work on the other side, or that all the attached applications will be able to reconnect and use them. So much has been glossed over with the vision of a new toy to play with...
Actually, it does have a killer feature for us: native spatial processing. That will cut our processing times by a huge amount.
-
Yup. That's what they say. That they want to verify everything. These are the same people that write stored procs with spaces in the column names, # signs, etc. We once spent a day tracking down a crash because the SQL dev "accidently" put a trailing space in the column name "ColumnName ". He swore up and down that he didn't change any column names and dev swore up and down that he did. Like I said before, I'm not a SQL expert and database doesn't interest me that much in general, so I'm not up on all the latest & greatest best practices, but I still know you shouldn't put spaces in column names, keep everything consistent, etc. Not have 11 copies of the same data copied all over the place, etc.
It used to be harder in the past, but it's rather easy to "parallel" the "thinkers" in DBA and QA with Express and Trial Versions of most anything; so when they do finally say "OK ... Do it your way!" (due to some pressure from "above"), you've already been up and running.
-
Dumb question... if you are a DBA and I came up to you and said "Here's a physical beastly box... 24 cores, ~140GB of RAM, plenty of flash storage... I need you to set up SQL 2016 on it and migrate this 10TB database from SQL 2008 R2" Assuming of course proper security and best practices, etc. Let's even "complicate" it and assume this 10TB database includes spatial data. How long would it take you? I have ZERO SQL admin experience other then slamming a few SQLs onto local machines or VMs and I think I could realistically get it setup and running in a day or two with plenty of breathing room. Yet, our supposedly experienced DBAs claim its going to take them 3 months!!! LOL... Unbelievable.
I know I am late to the party, but my first question to these requests is always "What are you REALLY trying to do?". Most people come at you with a problem to their solution instead of asking you for a solution to their problem. Once I sit someone down and have them tell me exactly what their problem is there is always a much simpler path to take instead of the putting the square peg in the round hole. In this situation you are describing I would be asking them what are you going to use this for? Are you expecting a handful of engineers on the enterprise hitting it? Or are you going for a web facing portal audience. How you plan to implement a SQL database really starts there.