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 Wednesday, April 3, 2013 9:36 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 8:53 PM
Points: 33,204, Visits: 15,353
Comments posted to this topic are about the item Development, Operations, or Accounting






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1438639
Posted Thursday, April 4, 2013 2:59 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, August 28, 2014 3:38 AM
Points: 986, Visits: 795
Steve Jones - SSC Editor (4/3/2013)
If I can't count on better services than I get in-house, I'm not sure there are many advantages to moving.

Well said that man.
Post #1438689
Posted Thursday, April 4, 2013 3:29 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 8:45 AM
Points: 1,049, Visits: 3,004
I doubt there's going to be much debate on this editorial, Steve. Expect to be Warnocked.

Semper in excretia, sumus solum profundum variat
Post #1438700
Posted Thursday, April 4, 2013 6:18 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:34 AM
Points: 7,098, Visits: 12,606
Yeah, what he said.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1438747
Posted Thursday, April 4, 2013 8:02 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, June 26, 2014 7:28 AM
Points: 257, Visits: 902
Steve Jones - SSC Editor (4/3/2013)
If I can't count on better services than I get in-house, I'm not sure there are many advantages to moving.


For the sake of discussion, I'll play devil's pedantic advocate... "better services" and "many advantages" might be subjective. :)

You could buy hardware, pay licensing costs, additional backup time/storage, and a DBA salary to have in-house services. You might even be able to find a DBA that is 100% dedicated to keeping everything running ideally-optimal. I have no idea how to estimate the true TCO for this setup.

You could make almost all of this someone else's problem for a fraction of that cost. Again, I am not familiar with true costs of cloud services under real-world usage patterns - but let's call it somewhere between 10% and 50%. I understand the initial purchase is depreciated but the DBA salary is probably fixed or rising over years as is the amount of data to backup, etc.

What is the percentage of downtime from a cloud provider? 1%? 5%? Now it's a matter of expected utility (ok, so that's a game theory term for "bet" or "gamble") Is it worth 10x the cost to reduce the 1% event to 0% (or 2x the cost to reduce 5% to 0%) This also perhaps unrealistically assumes the in-house error percentage is 0% - the question might be: is it worth 10x the cost to reduce the 1% failure of big/impersonal cloud to the 0.5% failure rate of an extra careful person-I-know.

If the cost of the 1% event exceeds the difference in maintenance cost for the in-house solution, the choice is clear. I imagine the real cost of that 1% downtime is frayed nerves for our stakeholders, but that lost revenue for small-mid size business is less than the cost to guard against.

I know a DBA isn't supposed to roll dice; however, in many cases there needs to be a balance between acceptable risk and cost to mitigate those risks.
Post #1438819
Posted Thursday, April 4, 2013 11:19 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, August 29, 2014 10:04 AM
Points: 2,299, Visits: 1,356
Mike Dougherty-384281 (4/4/2013)
... in many cases there needs to be a balance between acceptable risk and cost to mitigate those risks.


Nice!

Peace of mind is not worth spending half a million dollars to solve a problem that cost $50 that only happens once in a lifetime.


Not all gray hairs are Dinosaurs!
Post #1438923
Posted Thursday, April 4, 2013 11:26 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 8:53 PM
Points: 33,204, Visits: 15,353
Mike Dougherty-384281 (4/4/2013)
Steve Jones - SSC Editor (4/3/2013)
If I can't count on better services than I get in-house, I'm not sure there are many advantages to moving.


For the sake of discussion, I'll play devil's pedantic advocate... "better services" and "many advantages" might be subjective. :)

...


Good points. You may be right on some of these, after all, I've had SSL certs expire in house because our admin wasn't paying attention.

I'm not sure how to guess, but if service/support/performance isn't better, or much better, I know I'd rather take my chances most of the time in house. Mostly because I can work to improve things.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1438931
Posted Thursday, April 4, 2013 8:47 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Yesterday @ 9:58 AM
Points: 36,995, Visits: 31,517
One of the things that's usually implied or even explicitly expressed about using cloud services, such as Azure, is that you no longer need the expense of a DBA. While it's true that you may think you might be able to get away without a DBA, you're going to have many of the same problems without a DBA as if you had your own systems and you just don't not know it yet.

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. Do the same thing on Azure, and you're going to be paying the big bucks. A good DBA will not only find those problems, a good one will also know how to fix the code. A great one will prevent the problem from occuring in the first place by mandating code reviews/performance tests and putting a set of standards in place.

To give you a real live example of what I'm talking about, I just found and fixed a simple little bit of legacy code that consumed only 320ms of CPU time and only 66,000 reads for each run. Most would be very happy with that especially with the seemingly low resource usage. What no one else realized is that it runs 40,000 times in an 8 hour period. That's 12,800 CPU seconds (more than 3.5 hours) and 21.6 Tera-Bytes of logical I/O. I don't know how much those two items would cost according to current Azure pricing, but that's a waste even on "free" systems. I got it down so that it would run in 800 Micro Seconds and use only 4 reads per run and is scalable. The new 8 hour totals are only 320 CPU seconds (5.3 minutes) and 1.3 Giga-bytes of logical I/O. That's 39 times less CPU and more than 16,000 times less logical I/O. Another key point is that optimization was done AFTER 2 non-DBAs tried to optimize it and couldn't.

Don't kid yourself with the promise of super low TCO for cloud services because you think you don't need a DBA anymore. If you don't have a DBA, you're TCO may end up being a hell of a lot more than you thought and usually more than it should. This falls under the old but still very true saying of "Some people know the cost of everything... and the value of nothing."

Even with cloud services, like Azure, the value of a good DBA is inestimable but sure.


--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."

(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 #1439076
Posted Thursday, April 4, 2013 9:50 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Today @ 8:45 AM
Points: 627, Visits: 2,169
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




----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Post #1439080
Posted Friday, April 5, 2013 2:00 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, August 26, 2014 1:19 PM
Points: 67, Visits: 426
Usualy the contingency mission-critical databases and applications running on company hardware is done at an alternate location, or part of the infrastructure is duplicated to avoid outages. There is no reason to assume this is no longer necessary when you are using a cloud service. However, most cloud service providers do not yet support a scenario where you pay a very small fee for the ability to use a service only as a back-up when disaster strikes. Currently your only option for cloud services that are part of the mission-cirtical infrastructure is to spread them over different providers. I can only assume that you do this already with your internet connection, using several lines from different providers with different ISP's. Has anyone been involved in such a scenario?
Post #1439126
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse