SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Development, Operations, or Accounting


Development, Operations, or Accounting

Author
Message
Keith Langmead
Keith Langmead
SSC-Enthusiastic
SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)SSC-Enthusiastic (174 reputation)

Group: General Forum Members
Points: 174 Visits: 428
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.
lnardozi 61862
lnardozi 61862
SSC-Enthusiastic
SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)SSC-Enthusiastic (170 reputation)

Group: General Forum Members
Points: 170 Visits: 615
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.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (89K reputation)SSC Guru (89K reputation)SSC Guru (89K reputation)SSC Guru (89K reputation)SSC Guru (89K reputation)SSC Guru (89K reputation)SSC Guru (89K reputation)SSC Guru (89K reputation)

Group: General Forum Members
Points: 89919 Visits: 41146
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. :-P 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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Miles Neale
Miles Neale
Hall of Fame
Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)

Group: General Forum Members
Points: 3086 Visits: 1694
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!
Gary Varga
Gary Varga
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16915 Visits: 6534
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. :-P 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!!!
Marcia J
Marcia J
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1141 Visits: 1908
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search