SIG Meeting

I've just gotten the verbal OK from my line manager to attend the Management and Infrastructure SIG meeting on 4th October. Most of the opresentations look like they will be both interesting and useful. My employer is looking to introduce ITIL so the "Can it help me? What are the pitfalls?" presentation could be useful, similarly the DBA/Database ratio presentation is highly relevant to my current environment. The VLDB and Datawarehouse talks should be useful as some of ourdatabases are growing to be pretty huge, partly just datagrowth but also because we're getting situations where two or more separate applications (each with their own database) are being collapsed into one, total data volume has probably fallen but the data is now all in one place rather than being spread over two or more servers.

There's currently a big discussion going on about where the DBAs should sit in the organisation. In the background to the discussion are questions about what a DBA is and what a DBA does. There are a number of people who call themselves DBAs but are really application support people who happen to work mostly in the database, often doing little more than running prepackaged scripts and stopping/starting the database using OEM. They don't do any problem resoution (the problem resolution procedure is "Raise call with application vendor"), tuning or maintenence (other then running prepackaged scripts). Then there's a few people like myself who tend to do problem diagnosis and resolution, tune databases, set up servers, do proactive and preventative maintenence &c.

I was recently asked to give my thoughts on what a DBA does and landing up splitting it into three roles: Development DBA, Application Support DBA and Infrastructure DBA. here's my descriptions:

A Development DBA is one who does database side development as part of a development team, advises the front end/middleware developers (mostly about query tuning and fixing syntax/logical problems), create database objects and may administer (startup/shutdown, create users) the databases used in development. Tycally they will not be involved in installation of the Oracle software, creation of databases, setting up servers, server tuning, Oracle patching or anything outside of the development process. There is a good description of a development DBA here: http://www.oracledba.co.uk/tips/dba_evolution.htm

An Applications DBA is one who works as part of an applications support team to implement and support an application. They will be very focused on one particular application (or a small group of related applications) and typically will only deal with the schemas for that application. They tune queries, create and recreate objects as needed (mostly indexes) &c. Often they won't even have a login to the database server or have the sys/system passwords for the database. Typically they will not be involved in installation of the Oracle software, creation of databases, setting up servers, server tuning, Oracle patching (although they will patch the application) or anything outside of the application they support.

These first two are very much vertically oriented, stove piped even, they are only concerned with one application (either developing it or suppoorting it). Infrastrucxture DBAs, however, are very much horizontally oriented. They support the databases accross the organisation and are not restricted to just one application or small group of related applications. Infrastructure DBAs tend to be involved in pretty much everything to do with the database not covered by Application DBAs or Development DBAs, often they will advise or co-ordinate with Application DBAs.

Obviously there is a lot of grey area here, e.g. you might have an application DBA who patches the Oracle software but only on the machines their application(s) run on &c.

I'd describe myself as mostly Infrastructure with occasional flashes of Development.