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.
Listen to our latest podcast to hear DB2 expert Paul Stoker talk about how a Remote DBA service can help organisations of all sizes effectively manage their critical DB2 databases.
Our Brothers across the pond, DBI, have launched their new generation of performance monitoring software.Brother-Hawk sends automated, customised alerts based on the characteristics of real-time and recently computed data.Specifically for DB2 LUW databases it gives lights-out alerting of potential performance management issues.
This is added to their growing portfolio of DB2 performance management products.Particularly relevant at the moment is their database auditing solution, Brother Watchdog, which reduces corporate data risks by allowing organisations to track access and updates to corporate database data.
Updates have been applied to snapper (data collector), snapsave (recorder) and snapmon (web based front end) to allow snapsave and snapmon to support multiple collectors.
New test data was generated, and it is now apparent that some summarisation of the data will have to take place, as the javascript widgets providing spreadsheet and charting will not perform to acceptable levels with 500 entries to manage!
Next actions:
1. Add summarisation
2. Make snapsave multi-threaded to support multiple data colelctor sources more effectively.
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):
The snapshot server / daemon is just about finished – I need to build in some way of driving the shutdown event (already built into all of the threads) and put some additional events in to make sure that all of the snapshots threads are fully started before engaging the timer.
I’m planning to just use telnet to check that a data stream is being produced, but it’s all quite interesting at the moment.
Next on the agenda is the receiver, which will interpret the data streams and save the results off into a set of DB2 tables.
The current transmission method is over TCP/IP, but I’m thinking of externalising the comms to a replacable DLL, so that we can deliver data through a variety of different methods including MQ (probably).
I’ve started work on a UDB snapshot monitoring tool to gather and retain information from database servers. Only minimal thought has gone into reporting at the moment, but this will probably be web based.
The current proof of concept code can set the required monitor switches, gather all of the key snapshot data from the Admin API (db2GetSnapshot) and produce formatted reports. This represents most of the tedious grind work, so now it’s time to move onto the interesting bits and pieces – specifically:
Multi-threaded snapshot gatherer
TCP/IP communications between gatherer threads and the data store engine.
Data store engine.
(Probably) Apache / PHP front end with self refreshing pages showing status information
