Managing Cost of Oracle Investment during the Credit Crunch
Well, the credit crunch is here, and those of us working in the financial area are already feeling the direct impact. First, the feared job losses, followed by budget shortfalls. IT divisions are particularly feeling the heat.
- Operational areas not only are now operating with smaller number of DBAs, but also by exchanging experienced (but expensive) contractors with less experienced members of staff.
- Application teams are focusing more on BAU (Business as Usual), maintaining skeleton staff for each application area.
- The ratio of reduction in the number of developers perhaps is larger than the ratio of reduction in development work raised by the business demands.
Job cuts certainly save cost. The danger is if it results in extreme compromise in quality of support and development products due to unrealistic workload demands on already overworked staff.
The other avenue for cost cutting is server consolidation. Oracle charges its license by CPU. The more servers you have, the higher number of CPU accumulates, the more expensive it gets.
Rationalize your Oracle RAC domains. There are a lot of applications out there unnecessarily run on RAC configuration. Requirement for resilience is mistaken with requirement to run RAC. The difference? Well in money term, half the cost if you settle for single instance configuration, rather than RAC.
If you are planning to migrate an application to a bigger, better server, look again. Say, a high profile application seems to have outgrown its current environment, performance seems to degrade, SLA is being missed. A DBA team that is overworked, and isolated from the business/application team, would often agree to raise a request for a new server purchase, with more memory, more CPUs, more capacity. But in some cases, this costly purchase, configuration, migration, downtime could be avoided with:
- DBA team working closely with Application team
- Understand hot spot during a working day
- Is an Oracle backup interfering with the smooth running of a batch?
- Is a UNIX file system backup interfering with the application?
- Are maintenance work done at the wrong time on the server, thus impacting application performance
- Do application team have enough Oracle expertise to make the most out of their oracle database?
- Perhaps a tuning exercise is needed