The Case of the Shrinking CFO, err Database

Question

The Case of the Shrinking CFO, err Database

Viewing 2 posts - 31 through 31 (of 31 total)

You must be logged in to reply to this topic. Login to reply

Ray Herring SSCertifiable Points: 5533 More actions · Answer 1

Jeff Moden - Wednesday, January 3, 2018 10:23 AM
Ray Herring - Wednesday, January 3, 2018 9:57 AM
Three different points.
A.) It is not the DBA's job to convince the CFO and that approach is ultimately doomed. The DBA should be working with the database's business side stakeholders (HR, Sales, Manufactoring, ....). Let them work the budget issues with the CFO. You may even find that the business no longer needs the database.
II.) is the approach to "moving" the tables and indexes. I inherited a database with all objects in a single file in primary. As the database approached 600GB we faced the physical limits of the then available disks.
After adding disks, file groups, and files; I moved selected tables and indexes using index maintenance tools. Non-clustered indexes were moved by rebuilding on new file groups and clustered indexes were moved with "Create - Drop Existing"
3.) The CTO will have to go back to school. You can't expect to perform major maintenance actions with "No performance impact". You can minimize and spread out the impact but you can't prevent it.
I have to disagree with the first point. HR, Sales, and Manufacturing have no clue in the areas we speak of. Their discussions may actually hurt the cause if they're not properly prepped for the discussion. If there's no CIO and no infrastructure group, then the DBA is going to have to be the one to produce and deliver the convincing argument.
On that third point, it sounds like the CTO doesn't actually need to go "back to school" for this problem and was directing an under-prepared DBA to come up with a better plan than just throwing hardware at stuff.

Sorry Jeff I disagree. It is the Business's responsibility to justify the expenditure. If they can't understand the value proposition then you should find a new employer. Sales says 'We have to have a complete record of every transaction forever". I tell sales that will cost you xMB/Transaction/Year. How many transactions do you want? That's pretty simple math. Protects me by providing a basis for sizing and makes them justify the cost to the CFO.

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 2

Ray Herring - Wednesday, January 3, 2018 11:10 AM
Jeff Moden - Wednesday, January 3, 2018 10:23 AM
Ray Herring - Wednesday, January 3, 2018 9:57 AM
Three different points.
A.) It is not the DBA's job to convince the CFO and that approach is ultimately doomed. The DBA should be working with the database's business side stakeholders (HR, Sales, Manufactoring, ....). Let them work the budget issues with the CFO. You may even find that the business no longer needs the database.
II.) is the approach to "moving" the tables and indexes. I inherited a database with all objects in a single file in primary. As the database approached 600GB we faced the physical limits of the then available disks.
After adding disks, file groups, and files; I moved selected tables and indexes using index maintenance tools. Non-clustered indexes were moved by rebuilding on new file groups and clustered indexes were moved with "Create - Drop Existing"
3.) The CTO will have to go back to school. You can't expect to perform major maintenance actions with "No performance impact". You can minimize and spread out the impact but you can't prevent it.
I have to disagree with the first point. HR, Sales, and Manufacturing have no clue in the areas we speak of. Their discussions may actually hurt the cause if they're not properly prepped for the discussion. If there's no CIO and no infrastructure group, then the DBA is going to have to be the one to produce and deliver the convincing argument.
On that third point, it sounds like the CTO doesn't actually need to go "back to school" for this problem and was directing an under-prepared DBA to come up with a better plan than just throwing hardware at stuff.
Sorry Jeff I disagree. It is the Business's responsibility to justify the expenditure. If they can't understand the value proposition then you should find a new employer. Sales says 'We have to have a complete record of every transaction forever". I tell sales that will cost you xMB/Transaction/Year. How many transactions do you want? That's pretty simple math. Protects me by providing a basis for sizing and makes them justify the cost to the CFO.

In that case, we'll have to agree to disagree.

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

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)