As the bbq summer progressed, temperatures rose (well, there was that one week in May) and we all disappeared off on our Staycations, were the frazzled DBA team the only ones who got burnt?
Burnt-out that is. There are certain times during the year when the office looks distinctly empty. Summer holidays and Christmas being the most obvious. If you add a few summer colds (we’re not mentioning swine flu) and a couple of days off sick, things can get really sticky.
We all know how vital it is that our business critical databases are kept running and we’re able to give customers the high levels of support they depend on. However, this can be difficult during times when DBA teams are thin on the ground. Even more so if your DBA team provides cover 24/7.
Knowing that you have a back-up support team can help you to better plan for those times when the team is under extra pressure whether that’s due to holidays, sickness or seasonal spikes in business.
With a Consultancy on Demand contract you can purchase a block of hours and allocate them to be used during the year, when you need that little bit of extra support.
If your DB2 databases are used to support mission critical applications you’re likely to benefit from our Remote DBA service. Almost like an insurance policy on your database, Remote DBA is there if and when things go wrong. With Proactive Monitoring you can be safe in the knowledge that nothing will get missed.
The snapshot monitoring tool now has a data recording component for DBM snapshots that records the event and all of the details into a DB2 UDB database.
Work has started on a web-based front end (Apache / PHP / JScript) which includes user login and management and the initial tabular presentation of the snapshot data.
This will be extended this week to include some basic charting of the numeric columns using an open source JScript toolkit called Dojo, which seems to be gaining a lot of interest on the internet. This includes many “look and feel” aspects, but of particular interest is the tooltip, charting and dialog box functionality.
I hope to have a basic demonstration in place by the end of the week.
The data capture aspects (“snapper”) of the snapshot monitoring tool are now complete. Thread scheduling has been verified, along with the timer thread operation and the communications thread.
A small command line utility has also been written to tell snapper to shutdown.
Work has started on the receiver (“snapsave”), which will interpret the DB2 monitor data stream passed to it by snapper. The framework has been written (database connectivity, tcp/ip connection to snapper, monitor stream retrieval) and had some minimalistic testing.
Have just started work on the code to interpret the stream and save the results to DB2. The header record (first element) – which will be the parent data for any of the snapshot types is just about done.
Once this is working, I’ll start on the DATABASE MANAGER snapshot stream.
Once this is all tested and working nicely, I’ll do a little work on a Apache/PHP/Web-browser based front end. Just to prove it all hangs together, I’ll sort something out on this once the DBM snapshot decode is done.
Once we’ve proved the architecture, we can start work on the other streams. Current focus is on (all database specific):
