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

The Data Warehouse DBA Expand / Collapse
Author
Message
Posted Monday, December 4, 2006 9:32 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, July 17, 2014 7:55 AM
Points: 2,805, Visits: 3,067
Comments posted here are about the content posted at temp
Post #327699
Posted Thursday, December 14, 2006 7:47 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, September 23, 2010 10:14 PM
Points: 12, 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




Post #330499
Posted Thursday, December 14, 2006 7:55 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, August 20, 2014 4:03 PM
Points: 269, Visits: 485

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!




Post #330503
Posted Thursday, December 14, 2006 11:06 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, December 3, 2013 1:57 PM
Points: 394, Visits: 83

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.

 

Post #330603
Posted Thursday, December 14, 2006 11:46 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, August 24, 2014 5:23 PM
Points: 66, Visits: 529
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

Post #330613
Posted Thursday, December 14, 2006 11:54 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, August 20, 2014 4:03 PM
Points: 269, Visits: 485
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.



Post #330618
Posted Thursday, December 14, 2006 1:12 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 9:55 AM
Points: 3,214, Visits: 2,333

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."
Post #330645
Posted Wednesday, December 20, 2006 2:49 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, September 23, 2010 10:14 PM
Points: 12, 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

 




Post #331950
Posted Tuesday, December 8, 2009 9:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, February 3, 2010 8:00 PM
Points: 5, 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
Post #831162
Posted Wednesday, December 9, 2009 7:59 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, August 20, 2014 4:03 PM
Points: 269, Visits: 485
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.



Post #831427
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse