August 24, 2010 at 8:23 pm
Comments posted to this topic are about the item The DBA Financial Analyst
August 24, 2010 at 9:17 pm
the cloud might be more trouble than it's worth
'Nuff Said! 😉 Next problem please. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
August 25, 2010 at 6:55 am
"The DBA job is somewhat nebulous..."
And for those DBAs who find themselves working in the Cloud, the DBA job is very nebulous.
August 25, 2010 at 7:56 am
Our company's concept of "cloud" is that you have a large set of servers clustered by Polyserve that have many instances of SQL, and when an app needs a database, they pay for it by a fraction of the cost it originally cost the company to buy the hardware/software and don't care where in the matrix they live. We have a mechanical method of calculating the cost to the project. That sort of thing I can handle. But we stop at the DB and file/backup level. To calculate how much it would cost to add an index is not what I would want to do. What if you reindex? Drop indexes temporarily and readd them? How would you track costs for that? IMO going beneath the database level in calculating charges is too excessive for a DBA to have to deal with.
August 25, 2010 at 8:27 am
I definitely like the idea of a cloud like Polyserve. That seemed like a great technology.
August 25, 2010 at 8:29 am
As a systems/business analyst, my job borders on accounting a little more than I like sometimes. Every aspect of my job is financial: my time has a very real cost, and my job is to analyze that cost versus the benefit of a new program or project. Projects with the highest benefit to cost ratio get done first, projects with low benefit to cost ratios sometimes never get done. Also, I spend a lot of time with both the accounting and sales departments. Both departments send me on errands that inevitably end me up digging through the GL transaction table, or some other financial data. When our auditors need data, who do you think retrieves it? I've actually learned quite a bit about accounting from my job.
I'm also the DBA; more of an incidental DBA than anything else, but I am the sole DBA/database developer for our company. I manage two servers, including backups, disaster recovery, and monitoring. I'm a developer too in that I manage all of the code on the database servers, complete with version control. Implementation of a project often requires that I be all three: business analyst, DBA, and developer.
I've also worn a few other hats at my company. I did end user tech support for some time, as well as general troubleshooting for employee computer issues. I've gone away for both roles, however, as the system analyst role creates a lot more value for the company. Eventually, I'm sure I'll move up to senior systems analyst, but I will probably still be the lead DBA, and I will always be a developer. I'm sure I'll still be a little bit accountant, too.
I don't think my role with the company is a very unique one. This jack-of-all-trades role may not exist at very many large companies, but I'm sure there are plenty of small companies cutting cost by having people performing multiple roles.
Either way, the idea of being both a DBA and a financial analyst is far from new to me.
August 25, 2010 at 8:33 am
Steve Jones - Editor (8/25/2010)
I definitely like the idea of a cloud like Polyserve. That seemed like a great technology.
Is is SO much easier to support than MS clustering. You install, as an example, three local copies of SQL on three boxes with the same instance name and details, then Polyserve creates the virtual server and binds together the three installs into one. It's flexible, all nodes can see all drives (in contrast to another post elsewhere, Polyserve CAN share all of its drives across multiple instances) and it is easy to use. Only major issue we've seen is SharePoint -- Polyserve and SharePoint don't play nice together.
August 25, 2010 at 8:43 am
As always Steve, your commentaries seem to come at painfully appropriate times! I just helped accounting with a big financial analysis. Turns out the program they use to 'query' the database doesn't really build queries as much as it just adds a multitude of where clause criteria with no relationships.
From this experience, I would say either the DBA will need to begin to take on more of a financial analyst role or the financial analyst is going to need some basic training in db queries and table relationships.
Oh, and I liked that last little bomb you dropped on the cloud...forecasting clear skies? 😛
August 25, 2010 at 9:15 am
While I can see the point of determining the incremental costs of not only adding indexes but also things like stored procs, temp tables, and triggers as well as the cost of vs the savings from tuning queries, I can also see where it could easily cost more to do the analysis than it would bring in.
However, if one is charging for the space and execution time that a client is consuming (especially in a database hosting situation), I wonder if it might not be possible to create an application/process that could be provided a set of parameters (possibly saved in a CostBenefitAnalysuis database? 😉 that would allow for the automation of the analysis. Thus, you could have a monitor (e.g. my preferred tool, Ignite) that provides you with information about the Wait States of queries and then, based on the other information from the system (e.g. data storage, cycles consumed, bandwidth consumed, etc.) you could hit the client with an offer to tweak, say, their worst 5 performing queries at a cost of $X with a potential savings of $Y / month which (hopefully) would pay for the original cost in Z months (hopefully within the current fiscal year).
Ralph D. Wilson II
Development DBA
"Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the ax."
A. Lincoln
August 25, 2010 at 10:36 am
jeff.mason (8/25/2010)
Steve Jones - Editor (8/25/2010)
I definitely like the idea of a cloud like Polyserve. That seemed like a great technology.Only major issue we've seen is SharePoint -- Polyserve and SharePoint don't play nice together.
That's an unfair comment about Polyserve.
Sharepoint doesn't play nice with anything, even SQL Server.
Just issuing a SQL query against the Sharepoint SQL databases violates the support agreement.
If that isn't the definition of not playing nice with your own database, I don't know what is.
August 25, 2010 at 10:54 am
david_wendelken (8/25/2010)
jeff.mason (8/25/2010)
Steve Jones - Editor (8/25/2010)
I definitely like the idea of a cloud like Polyserve. That seemed like a great technology.Only major issue we've seen is SharePoint -- Polyserve and SharePoint don't play nice together.
That's an unfair comment about Polyserve.
Sharepoint doesn't play nice with anything, even SQL Server.
Just issuing a SQL query against the Sharepoint SQL databases violates the support agreement.
If that isn't the definition of not playing nice with your own database, I don't know what is.
Fair point. That's not meant by me as a slam against Polyserve. I only mention it because we had to expell SharePoint our of our Polyserve matrix because SharePoint errors would bring down the entire matrix, i.e. ALL apps and the whole cloud. That was unacceptable, and the decision was that Polyserve would always be at risk for that with SharePoint. Among our DBA group SharePoint has become a dirty word and it was our idea to get it off our servers onto its own little cluster so if it decides to take its toys and go home, it doesn't impact anything else.
August 25, 2010 at 8:02 pm
RalphWilson (8/25/2010)
While I can see the point of determining the incremental costs of not only adding indexes but also things like stored procs, temp tables, and triggers as well as the cost of vs the savings from tuning queries, I can also see where it could easily cost more to do the analysis than it would bring in.However, if one is charging for the space and execution time that a client is consuming (especially in a database hosting situation), I wonder if it might not be possible to create an application/process that could be provided a set of parameters (possibly saved in a CostBenefitAnalysuis database? 😉 that would allow for the automation of the analysis. Thus, you could have a monitor (e.g. my preferred tool, Ignite) that provides you with information about the Wait States of queries and then, based on the other information from the system (e.g. data storage, cycles consumed, bandwidth consumed, etc.) you could hit the client with an offer to tweak, say, their worst 5 performing queries at a cost of $X with a potential savings of $Y / month which (hopefully) would pay for the original cost in Z months (hopefully within the current fiscal year).
That's where the financial analisys stuff shouldn't be left to be a side job by relucatant amateurs (like most DBA's would aspire to be). Quantifying possible direct costs only leads to making ultimately bad decisions about how to run your server and/or your business: you end up scrimping on spindles/ free space, end up running auto grow AND auto-shrink with ludicrously small growth increments against shared luns with EVERY application on the planet partaking of the shared LUNs. All for the sake of "optimizing" your cost allocations to the various application and project teams.
Why? because it's so much harder to quantify all of the things you give up when you run with ridiculous settings like that. The fact that the average request will quickly degrade to taking multiple times longer than before, the disk contention headaches, etc... are usually NOT easy to quantify until of course the CIO, CFO and CEO show up screeching that the Accounting department is taking th day off because their applications just won't load anymore.... Opportunity costs and soft costs are almost impossible to figure correctly and even harder to allocate.
I've been stung by this before, and let me just share my response to them at the time: No Mas, Gracias y Hasta La Vista.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 26, 2010 at 8:07 am
Matt Miller (#4) (8/25/2010)
Why? because it's so much harder to quantify all of the things you give up when you run with ridiculous settings like that. The fact that the average request will quickly degrade to taking multiple times longer than before, the disk contention headaches, etc... are usually NOT easy to quantify until of course the CIO, CFO and CEO show up screeching that the Accounting department is taking th day off because their applications just won't load anymore.... Opportunity costs and soft costs are almost impossible to figure correctly and even harder to allocate.
Completely agree, though I think that problem can be extended in the other direction. How many of us are handed an existing database setup and have to attempt to make it work better.
Knowing that adding indexes here and there is good practice, adjusting this or that will prevent an obvious bottle neck, or increasing the db size will prevent growths during the day etc is all well and good, but how easily can we quantify what difference each of those changes will make?
We're into the realms of having to know exactly what benefit each thing will make. 'Dear budget holder, adding x index will improve performance of these queries by y percent while costing us z money... do you want me to do it or not?'
August 26, 2010 at 8:27 am
The cost and benefit of an index is extremely hard to calculate.
Assuming all resources have a cost, adding an index will consume more disk space($) but can reduce disk IO($), CPU usage($), and memory usage($). Also, if it makes things run faster, it can allow end users to get more work done in less time($).
The problem with cost accounting systems is that they tend to concentrate on measuring the resources that are easy to measure and assign a dollar value to (disk space) and do not effectively deal with things that are hard to quantify exactly (change in CPU, disk IO, memory usage, or user experience), but have a very real business cost.
August 26, 2010 at 8:33 am
We really are in the business of "soft" benefits. It may be difficult to analyze the benefit of changes like you said, but we've generally got a good feeling of when something is worth the effort. I "gut cost" things all the time. When in doubt, I tend to experiment. When the cost is low, calculating actual cost/benefit is hardly worth it. When the cost is high, I may need to actually write up a business case.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply