Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
IMS Database Crash
- Thread starter SowKan
- Start date
IMS databases don't crash, they tend to get corrupted instead, as they use a lot of explicit RBA pointers.
If you are running some sort of database analyser(DB-analyser or SMU-II pointer checker) regularly you should have warnings showing you what's wrong.
You really only need to worry about broken pointers in the data portions - indexes and secondary indexes can always be rebuilt and you should have housekeeping jobs already set up to do this.
If you have broken pointers in the data itself, proceed as follows:
0. Back up what you've got already. Dual copies. Don't compromise on this.
1. Find out when it got broken. If you run DB-analyzers regularly, and keep the output, you should be able to figure it out.
2. Find out when the last image copy was taken before the problem occurred.
3. Make sure you have IMS logs (journals) for any updates applied between the last image copy, and the time of failure. If you run batch updates without logging, you'll have to go back to the last image copy, so you can skip step 5 (and 7, as you already have an image copy)
4. Restore the database(s) involved to the last image copy before the problem.
5. Run a forward recovery to apply the logged updates to your database.
6. Run DB analyser on the resulting database.
7. If it's OK, run an image copy.
8. If not, you have a problem. It is possible to knife-and-fork IMS databases back together by directly editing the pointers. I went on a five-day course back in the 80's to learn how to do it, and have had to do it a couple of times with production data. But I *really* wouldn't recommend it...
Hope this helps
Steve
If you are running some sort of database analyser(DB-analyser or SMU-II pointer checker) regularly you should have warnings showing you what's wrong.
You really only need to worry about broken pointers in the data portions - indexes and secondary indexes can always be rebuilt and you should have housekeeping jobs already set up to do this.
If you have broken pointers in the data itself, proceed as follows:
0. Back up what you've got already. Dual copies. Don't compromise on this.
1. Find out when it got broken. If you run DB-analyzers regularly, and keep the output, you should be able to figure it out.
2. Find out when the last image copy was taken before the problem occurred.
3. Make sure you have IMS logs (journals) for any updates applied between the last image copy, and the time of failure. If you run batch updates without logging, you'll have to go back to the last image copy, so you can skip step 5 (and 7, as you already have an image copy)
4. Restore the database(s) involved to the last image copy before the problem.
5. Run a forward recovery to apply the logged updates to your database.
6. Run DB analyser on the resulting database.
7. If it's OK, run an image copy.
8. If not, you have a problem. It is possible to knife-and-fork IMS databases back together by directly editing the pointers. I went on a five-day course back in the 80's to learn how to do it, and have had to do it a couple of times with production data. But I *really* wouldn't recommend it...
Hope this helps
Steve
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question