Hi there,environment before we can run our test scripts to validate the backup.
we regularly use backups from production db's to test recovery and rollforward. A few weeks ago we did some schema changes and added a few indexes and such. Since then, we have to rebind the same package every time we restore/rollforward on our testing
What do we have to do to avoid this? How can we determine which packages need to be rebound?to rebind all the packages that needed rebinding in our testing is not working on the illness, just on the symptoms, right?
The risky thing about this is that in case of emergency, when we need to restore the DB in production, there is no time for games like stumbling from one rebind to the next... I am sure writing bash scripts to accompany our restore/roolforward scripts
we regularly use backups from production db's to test recovery and rollforward. A few weeks ago we did some schema changes and added a few indexes and such. Since then, we have to rebind the same package every time we restore/rollforward on our testingenvironment before we can run our test scripts to validate the backup.
What do we have to do to avoid this? How can we determine which packages need to be rebound?
The risky thing about this is that in case of emergency, when we need to restore the DB in production, there is no time for games like stumbling from one rebind to the next... I am sure writing bash scripts to accompany our restore/roolforward scriptsto rebind all the packages that needed rebinding in our testing is not working on the illness, just on the symptoms, right?
What do we have to do to avoid this? How can we determine which packages need to be rebound?
This is not a normal part of restore and rollfoward operation.
What packages are you having to rebind? Are they your own application's packages, or are they system packages (i.e. in NULLID schema)?
If it's your own application's packages, I can only imagine this being a necessity if the packages were already invalid when you took the backup that you're restoring, or if they were invalidated (by DDL changes that occurred between the backup and thepoint-in-time that you recovered to, but before rebinds occurred). The solution to this problem is to ensure that finding and fixing invalidated packages is part of any deployment.
scripts to rebind all the packages that needed rebinding in our testing is not working on the illness, just on the symptoms, right?
The risky thing about this is that in case of emergency, when we need to restore the DB in production, there is no time for games like stumbling from one rebind to the next... I am sure writing bash scripts to accompany our restore/roolforward
You can see invalid objects by querying SYSCAT.INVALIDOBJECTS. (Assuming you're using Db2 on Linux, UNIX or Windows).
Also (again, if you're on Linux, UNIX or Windows) you may want to look at the ADMIN_REVALIDATE_DB_OBJECTS procedure.
Thanks for that pointer. I called it using zero parameters and the table invalidobjects is now empty. I will see if the next backups will work better when they are restored...
Hi Joachim,
Are the stored procedures external ones (i.e. not SQL procedures)? I'm wondering if behaviour after restore might then be different.
Is the instance fix pack level definitely identical in both environments? See https://www-01.ibm.com/support/docview.wss?uid=swg22002381
Jeremy Rickard
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 295 |
Nodes: | 16 (2 / 14) |
Uptime: | 04:52:38 |
Calls: | 6,642 |
Calls today: | 2 |
Files: | 12,190 |
Messages: | 5,325,847 |