The Boring Non-Core-DBA-Tasks in a project

To begin with, this is NOT a typical appsdbatechstuff blog which would talk about issues and solutions. I thought of penning this down as we have just completed a massive project where we migrated a two node 9i RAC/ 11.5.9 Oracle apps instance to 4 Node 11g RAC / R12.1.1 / OATM / 11g DataGuard on Linux.

During the course of the project, one of the sentiments which used to come to the fore on many occasions, was the dislike towards performing non - dba - technical activities. Now, the ambit of dba-technical activities would be the tasks which are part of the actual technical migration/upgrade and the non-core-dba activities would include anything to the tune of documentation, implementing standards, purging old crons, fixing perl issues, making custom old scripts work with new Oracle tech stack version, post-go live stabilization tasks, coordination with other teams on custom solutions, backup automation and so on....hope you get a sense of it..

From my experience of working in projects so far, i would say the actual upgrade or migration tasks which we perform constitutes only 30-40% of the actual project effort. The rest is environment specific stuff. Pretty much every environment specific custom solution has a business purpose behind it. That could be reducing the MTTR, preventing incidents, improving performance and thereby end user experience etc.

Hence, it is of paramount importance that at no point in time must we forget that we are executing the projects for achieving business results and not for the love of upgrade or migration. This implicitly means that our objective must be to make the database manageable from an operational perspective. An example could be setting up crons to alert the DBAs to an abnormal situation where more number of sessions are waiting on a event beyond the threshold, which may help DBAs act proactively and prevent an business outage.

One other aspect is that many of these non-core-dba-technical activities are aimed at making the environment stable and manageable. Further, as far as documentation is concerned, this makes sure that we dont carry mistakes from one iteration to another to finally production and make sure that all known issues are taken care of before we release the production.


I have only touched upon the need to work on the non-core-dba-technical tasks superficially in this blog.

However, one thing is for certain: I believe it needs to be treated with the same diligence and priority as core-dba-technical tasks because we should not forget the business objectives of the project.

-Aravind Kamath Posral