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


The Case of the Shrinking CFO, err Database


The Case of the Shrinking CFO, err Database

Author
Message
Ray Herring
Ray Herring
SSCarpal Tunnel
SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)

Group: General Forum Members
Points: 4386 Visits: 708
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
Jeff Moden
SSC Guru
SSC Guru (872K reputation)SSC Guru (872K reputation)SSC Guru (872K reputation)SSC Guru (872K reputation)SSC Guru (872K reputation)SSC Guru (872K reputation)SSC Guru (872K reputation)SSC Guru (872K reputation)

Group: General Forum Members
Points: 872915 Visits: 47503
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.
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
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