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

Development, Operations, or Accounting Expand / Collapse
Author
Message
Posted Friday, April 05, 2013 5:19 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, August 29, 2013 1:44 PM
Points: 144, Visits: 426
I think Mike and Miles are spot on, in many cases it's simply not cost effective to throw money at making a system that little bit more redundant, but at the same time you have to be aware of those limitations.

I think at times the fault lies with the perceived notion that cloud hosting is the obvious way everything is going, that it has no issues, and everything will be better in the cloud. The providers tend to prey on issues we see in our own setups, server crashes, hardware failures, time and money spent on backups etc, and tell us none of those things will be an issue if we move our data to them. Of course the reality isn't that straight forward.

In your office if someone fails to renew a domain or certificate you can if need be grab the bosses credit card and just get it sorted, when someone else's in control though you don't have that option, you just have to trust that they'll get things resolved quickly.

If you put your email into Office 365 then MS make sure it's backed up, great, except they only do DR backups to cover things if their servers die. If you delete some critical email from a mailbox and haven't setup your own backups then you're out of luck, MS don't offer any way to restore that data (according to their documentation).

To many people these things aren't an issue, but you need to be aware of them when you're choosing whether to move to the "cloud", and make sure management are aware of the limitations as well as the benefits.

I am surprised things like Azure don't offer more in terms of DR setups for cold / warm standbys, perhaps there's a reason or perhaps they're missing a trick. I'd love to clone some critical boxes into a 3rd party cloud setup, leave them suspended, and be able to fire them up if our own setups / DC's had issues, but the cost seems almost as much as if we were using them live.
Post #1439165
Posted Friday, April 05, 2013 6:58 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 10:53 AM
Points: 100, Visits: 487
Nothing can take the place of someone who takes it personally when the system sucks. It may be 'only a job', but programmer isn't what I do, it's who I am. Having people like us is what keeps the whole world from collapsing. The suits treat us like we're fungible, but we're NOT. Respect for the way we see ourselves is the prime attribute of the developer/dba.
Post #1439187
Posted Friday, April 05, 2013 7:09 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 6:29 PM
Points: 35,977, Visits: 30,266
Jim P. (4/4/2013)
Jeff Moden (4/4/2013)
For example, if you have some performance challenged code that uses a huge number of resources because someone simply used DISTINCT to get past an accidental Many-to-Many join, it won't cost you much on your own hardware.


I was moved from doing a DBA for a product that had multiple separate installations to a product that had every customer in a single silo. The development (and supposedly production) DBA's were on the left coast while the silo was on EST. I'm going to use the term DBA very loosely because of all the errors I found. One of the steps I did was to add in a free monitoring tool* just to see the high cost queries and other stuff.

I found an SP that was returning a list of 27K employees for 500+ individual facilities every time it was run. They were then evaluating the list in the web front end. The SP was running more than 5000 times per day. It was a quick SP, but totally wasted I/O. Adding a facility ID to the SP changed the results to about 25, and the I/O was significantly decreased.

So the development DBA needs to be watched. And tuning local or remote is always a problem.

* = Confio Ignite Free


Now that's what I'm talking about. But, those don't sound like "Development DBAs". Those sound like developers that think they know SQL Server because their system used an ORM to talk to SQL Server. All of the true Development DBAs I know (which are mostly on this site, BTW), wouldn't have allowed such a thing to happen never mind having written such terrible code.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1439191
Posted Friday, April 05, 2013 9:27 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, March 10, 2014 5:44 PM
Points: 2,225, Visits: 1,258
Keith Langmead (4/5/2013)I think at times the fault lies with the perceived notion that cloud hosting is the obvious way everything is going, that it has no issues, and everything will be better in the cloud. The providers tend to prey on issues we see in our own setups, server crashes, hardware failures, time and money spent on backups etc, and tell us none of those things will be an issue if we move our data to them. Of course the reality isn't that straight forward.


Very well said! Vendors continue to try and sell us the "silver bullet" that will solve it all. But none exists. We have to take into consideration with each decision about cloud issues, is this really the appropriate place for the data/application and/or the right use of resources to support and operate it? Everything should not be cloud. And the historic idea that all roads lead to Rome ignores the fact that all roads also lead away from Rome as well. Or there are things that should go there, and things that should not or should leave there.

Sorry for the ramble but you are spot on.

M.


Not all gray hairs are Dinosaurs!
Post #1439288
Posted Monday, April 08, 2013 7:13 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:20 AM
Points: 4,862, Visits: 2,243
Jeff Moden (4/5/2013)
Jim P. (4/4/2013)
Jeff Moden (4/4/2013)
For example, if you have some performance challenged code that uses a huge number of resources because someone simply used DISTINCT to get past an accidental Many-to-Many join, it won't cost you much on your own hardware.


I was moved from doing a DBA for a product that had multiple separate installations to a product that had every customer in a single silo. The development (and supposedly production) DBA's were on the left coast while the silo was on EST. I'm going to use the term DBA very loosely because of all the errors I found. One of the steps I did was to add in a free monitoring tool* just to see the high cost queries and other stuff.

I found an SP that was returning a list of 27K employees for 500+ individual facilities every time it was run. They were then evaluating the list in the web front end. The SP was running more than 5000 times per day. It was a quick SP, but totally wasted I/O. Adding a facility ID to the SP changed the results to about 25, and the I/O was significantly decreased.

So the development DBA needs to be watched. And tuning local or remote is always a problem.

* = Confio Ignite Free


Now that's what I'm talking about. But, those don't sound like "Development DBAs". Those sound like developers that think they know SQL Server because their system used an ORM to talk to SQL Server. All of the true Development DBAs I know (which are mostly on this site, BTW), wouldn't have allowed such a thing to happen never mind having written such terrible code.


Hey, I'm a developer (not a DBA at all) and I wouldn't have done that. There comes a point when it is just poorly, if at all, thought out. I guess in the context of the editorial you cannot get rid of the experts whilst systems are complex or custom (more than just visually).


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1439808
Posted Monday, April 08, 2013 3:43 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: 2 days ago @ 1:52 PM
Points: 266, Visits: 919
lnardozi 61862 (4/5/2013)
Nothing can take the place of someone who takes it personally when the system sucks. It may be 'only a job', but programmer isn't what I do, it's who I am. Having people like us is what keeps the whole world from collapsing. The suits treat us like we're fungible, but we're NOT. Respect for the way we see ourselves is the prime attribute of the developer/dba.


Very much agree.
Post #1440038
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse