SQLServerCentral / Discuss Content Posted by Janet Wong / Article Discussions / Article Discussions by Author / The Data Warehouse DBA / Latest Posts

RE: The Data Warehouse DBA

bnordberg — Wed, 09 Dec 2009 07:59:01 GMT

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

RE: The Data Warehouse DBA

melina386 — Tue, 08 Dec 2009 21:58:14 GMT

to read more about data warehouse DBA link is herehttp://oracledoug.com/serendipity/index.php?/archives/1011-Whats-a-Data-Warehouse-DBA.html[url=http://e-datapro.net]Data Entry India[/url]

RE: The Data Warehouse DBA

mahershaheendba — Wed, 20 Dec 2006 14:49:00 GMT

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

RE: The Data Warehouse DBA

rudy - Doctor "X" — Thu, 14 Dec 2006 13:12:00 GMT

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

RE: The Data Warehouse DBA

bnordberg — Thu, 14 Dec 2006 11:54:00 GMT

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.

RE: The Data Warehouse DBA

EugeneZ-162636 — Thu, 14 Dec 2006 11:46:00 GMT

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

RE: The Data Warehouse DBA

Sreejith Sreedharan — Thu, 14 Dec 2006 11:06:00 GMT

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.

RE: The Data Warehouse DBA

bnordberg — Thu, 14 Dec 2006 07:55:00 GMT

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!

RE: The Data Warehouse DBA

mahershaheendba — Thu, 14 Dec 2006 07:47:00 GMT

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

The Data Warehouse DBA

Loner — Mon, 04 Dec 2006 21:32:00 GMT

Comments posted here are about the content posted at temp