16 July,2013 by Jack Vamvas
During a DB2 database Physical 2 Virtual (P2V) migration , the systems administrator did not request for the application be shut down. The usual practise for a P2V is to shut down the application and shut down DB2 – then start P2V. This didn’t occur and resulted in a potential corruption.
When I restarted the DB2 server instance and attempted a db2 connect – the DB2 database wouldn’t progress with a successful connection. After some db2diag.log investigation and a DB2 instance restart – a message appeared:
ADM1532E Crash recovery has failed with SQLCODE "-1042". Roll Forward to a point in time before the transaction log entry is replayed.
At this point , I did a quick check on db2adutl and confirmed there was a valid backup and logs up to 10 minutes before the P2V occurred and satisfied the Recovery Point SLA - and . But it would be interesting to investigate why this issue arose.
First step – run these three commands , which return a significant amount of detail and can supply some clues . As well as the scenario I’ve outlined – this troubleshooting process is useful for all types of issues
Logon as with sufficient privileges to Database Server and issue these commands. The db2pd command in particular can offer tons of insight about what is occurring on the database server
1. db2 get snapshot for applications on 2. db2 get snapshot for db on --runs all options on all dbs 3. db2pd -everything