Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Data Warehouse DBA


The Data Warehouse DBA

Author
Message
Loner
Loner
Hall of Fame
Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)Hall of Fame (3.2K reputation)

Group: General Forum Members
Points: 3160 Visits: 3347
Comments posted here are about the content posted at temp
mahershaheendba
mahershaheendba
Grasshopper
Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)

Group: General Forum Members
Points: 14 Visits: 11

Great article and defining data warehouse DBA is excellent. I want to add that Production DBA cares more about performance while Development DBA just wants result to be correct and match the books. For Production DBA 30,000 reads is unacceptable and consumes resources while the Development DBA just want the correct answer regardless of the amount of reads. Also Production DBA need to now why the System is Locked and which SPID to sacrifice to get the Server back to Business. Also the Production DBA would need to now more Windows Enterprise techniques to help navigate SQL server through and able to pinpoint if the performance issue due to Windows/SP code/IIS issues.

Maher Shaheen





bnordberg
bnordberg
Old Hand
Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)

Group: General Forum Members
Points: 355 Visits: 569

One thing missing in the DW DBA article is the ability for the DBA to adapt quickly. Datawarehouses typically aggregate data and may only use a subset of OLTP data. While on Monday a field is not needed, by Tuesday it may be critical to business. If you cannot quickly adapt, by the time you react you have missed critical timing or missed a trend (good, bad or whatever). I put together data for medical trending. Outbreaks, new dangerous trends, new drugs that may cause good or bad outcomes ... All come at you quickly and if you cant' quickly modify your design and load data, then don't bother.

Also if you don't like granting access to your data, or feel you are the only one that can write SQL - you will be a datawarehouse log jam!





Sreejith Sreedharan
Sreejith Sreedharan
SSC-Addicted
SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)SSC-Addicted (487 reputation)

Group: General Forum Members
Points: 487 Visits: 89

Having worn 3 hats at the same time for my previous employer I totally agree with the article. My 2 cents.

1.Prod DBA should be available 24/7 ready for any emergency.
2.Dev DBA get ready to work long hours to meet the deadlines.
3.Data warehouse DBA: Understand your company's data and expect to get calls from higher up to help them understand why they the company data is different from what they thought.

After I left they hired 3 people to do the Job.


EugeneZ-162636
EugeneZ-162636
SSC-Enthusiastic
SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)SSC-Enthusiastic (106 reputation)

Group: General Forum Members
Points: 106 Visits: 562
Good article.

Old problem: production and not production DBAs (OLAP or\and OLTP)

DBA is DBA - needs to protect data regardless where it is located ("dev", "test", "prod" box)

Also if there are any sql server related problem that can effect company: such as Sql server dev (test) box went down and 1-20 developers can not work however company must pay them during the downtime and if there was not backup developer (company) can lose 100s hours of work x $$$->It is Production issue.

There is just an illusion that production ,development, test ,QA, etc are independed parts - > all it is PRODUCTION:

Production is the act of making things, in particular the act of making products that will be traded or sold commercially. Production decisions concentrate on what goods to produce, how to produce them, the costs of producing them, and optimizing the mix of resource inputs used in their production. This production information can then be combined with market information (like demand and marginal revenue) to determine the quantity of products to produce and the optimum pricing.

http://en.wikipedia.org/wiki/Production%2C_costs%2C_and_pricing


bnordberg
bnordberg
Old Hand
Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)

Group: General Forum Members
Points: 355 Visits: 569
I disagree. There is a huge difference between OLAP and OLTP production - at least in our environment. In our hospital if the OLTP system goes down, patient care suffers as we move to paper methods of tracking blood, samples ... If our warehouse goes down, we may miss some trends, but the overall effect is way, way, wayless than the OLTP. And very, very rarily do our analysts use the warehouse outside of the 8-5 window. So if it goes down at night, no biggie. I would love to only have to worry about OLAP systems it would allow me to sleep many more nights.
Many would argue that they have critical OLAP systems that drives supply orders, bed boards, medication orders ... I would argue that, you don't have an OLAP system, but a ODS instead. And with our terrible hospital OLTP systems an ODS is usually a necessary item - but it should be managed as an OLTP system.



Rudyx - the Doctor
Rudyx - the Doctor
Hall of Fame
Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)

Group: General Forum Members
Points: 3971 Visits: 2499

I too have worn all 3 hats (now I'm down to 2)

It is you, the DBA; you are the 'steward' of your organization's data. It is your role and more importantly, responsibility, to insure the data's integrity, its availability to the user community and the recoverability of the data with minimal to no dataloss. All of these large and broad tasks must be performed within specific business guidlines. It does not matter if the system is OLTP, batch or DSS. It does not matter if the server is Production, QA, Systen Test, Test,Development. They are all just names, categories, whatever. What counts is the SLAs (Service Level Agreements). Each system/database/application contains data, each of these systems/databases/applications has specific recovery criteria and each of these systems/databases/applications application(s) have their own SLAs (Service Level Agreements) that specify system availability.

So the bottom line is simply the following:

  • Its all DBA work
  • Its all production
  • It all has a priority
  • It all has importance


Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
mahershaheendba
mahershaheendba
Grasshopper
Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)Grasshopper (14 reputation)

Group: General Forum Members
Points: 14 Visits: 11

My comment is to bnordberg, we're not comparing OLAP to OLTP importance. The original articles only announce the new era for Data warehouse DBA and demand recognitions. For company to succeed it must leverage their existing data and use Business Intelligent to either generate new opportunity or enhance services.

Also some hospitals does utilize OLAP as a matter of life or death, example Discharge a patient of Emergency dependent on aggregated information not on OLTAP. Also Medications dispensing is dependent on OLAP. So as you see if OLAP goes down then you could not accept new patience unless you empty your hospital beds first. So it is all in the design, a good Business Intelligent will use OLAP design to ease the load off OLTP.

Thanks

Maher





melina386
melina386
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 Visits: 6
to read more about data warehouse DBA link is here
http://oracledoug.com/serendipity/index.php?/archives/1011-Whats-a-Data-Warehouse-DBA.html
Data Entry India
bnordberg
bnordberg
Old Hand
Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)Old Hand (355 reputation)

Group: General Forum Members
Points: 355 Visits: 569
Bill Inmon also has a interesting article: What a Data Warehouse is Not
http://www.b-eye-network.com/view/11352
Where he sounds off about what we are terming a Data Warehouse.



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