Archives of the TeradataForum
Message Posted: Fri, 12 Jul 2002 @ 17:10:19 GMT
We had a lot of trouble at Boeing during a system rehost some years ago *caused* by misuse of restore, so I wanted to let people know restore was not always the solution.
Our user community was nervous about the risk of a hard cutover for the entire system, so we decided to phase the rehost over about three months. The applications were grouped so that the dumps were about the same size, and we set up a schedule where we rehosted one group every two weeks. We then told the users that they couldn't change anything for the duration of the rehost (no new object ids), and they agreed.
We did a sysinit and a DBC restore, then restored the first few application groups with no problem. But the fun began about halfway through the process. We began having problems with the restores because of duplicate object ids. Root cause: some of the DBAs broke their promise not to change anything. Objects were being modified, dropped, dropped & recreated, you name it. The restores hated it. We finally limped through the last rehost with a copy and lot of grants, but it wasn't pretty.
If we had it to do over, we would either do the hard cutover or plan for the copy from the start (capturing the access rights as grant statements to be run on the new system). We're planning on merging two systems in about 18 months, so we'll be doing a restore for one and copy+grants on the other.
Hope it works... :)
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|