If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

yes, I am responsible for creating stored procedures / UDFs, binding packages in production environment...but, developer or development DBA creates them in dev, test systems..Dev DBA sends me the code and I execute them in prod.

We had development DBAs and production support people (they were not really called DBAs) - mainframe shop.

I've heard there are now different types of DBA for DB2 LUW - application DBA, system DBA, operational DBA... Do you have something similar at your organization? If you do, what is their role? To me, application DBA sounds more like a development DBA and system/operational DBA is more like a production DBA.

Application developers who are intersecting with databases should have a firm grasp of stored procedures , indices etc , and be able to develop with a view to optimising data retrieval. They should work in conjunction with Production\Development DBA

Bella, our organization has the concept of application dbas and operational dbas. Application dba is responsible for all devolopment stuff which includes writing stored procedures, udfs, etc... while operational dbas are responsible for production support.

Duties: For creating the databases application dbas needs to provide the number of tablespaces and their sizes to operational DBA team. Based on that we, operational/production dbas will work with AIX and SAN team for creating databases. operational dbas are responsbile for creating all the test, qa and production databases. Application DBAS are typically given dbadm for test databases so that they can execute DDL such as creating tables, views indexes, stored procs, udfs etc on to the test database. But for promoting them to QA or production they should open a ticket to operational DBA team so that operationl DBA can execute them on to QA/production.

Each application has its own application DBA but operational DBAs are responsible for supporting all the applications in the organization and provide oncall support for all the production databases in the organization

Making decisions for DR, replication, licensing etc.. would also be in the hands of operational DBA team and their manager.

Regarding JDBC and cli, operational DBAs provide the required JDBC drivers and the application DBAs are responsible for configuring their applications to use JDBC or so forth..

blazer789, it's interesting that production DBAs also take care of test/QA environments. This was not the case at our company. Prod support people were responsible for implementing changes (not only database related changes) to production. Test env was partially handled by dev DBAs.

I said that Application DBAs are given dbadm authority on TEST databases so they can totally handle test environment. Operational DBAs are only responsible for creating the test databases and performing sysadm duties like altering tablespaces, altering bufferpools etc.. which cannot be done by DBADM authority.

QA and Production environment will be handled by operational dbas. The reason why we don't want to give QA environment to application team is because we wanted to keep the QA system similar to that of Production.

The main difference between QA and Production environments in our organization is that the application team will have select insert update delete on the QA database but they would just have select on production.

Ha! When I was in the development team I did the database development. Then when I joined the dba team I was told that they didn't have anyone in the development team to do the database development work and it should be moved to the dba team (guess who got that one?).

When they gave me DB2 to look after, I had one training course, someone appeared as if by magic and said "You look after DB2 now" then ran off making Zoidberg like whooping noises. That was my handover.