Archives of the TeradataForum
Message Posted: Mon, 02 Jul 2002 @ 00:37:22 GMT
If I were going to maximize my testing, and I had time, I'd do this:
1. Sysinit the new system and install V2R3 on it.
2. Dump the old system and load it on the new one. You have to practice this anyway.
3. Collect SQL from your batch jobs, standard queries and ad hoc queries (access log) and organize it so you can run it as several benchmark streams.
4. Run the benchmark streams and collect the results so you can compare the results on both systems.
5. Modify the benchmark streams to capture explains for all the queries on both systems and save them.
6. Upgrade the *new* system from V2R3 to V2R4. This is good practice also.
7. Rerun the queries and the explains on the new system and look for trouble. You may want your advanced users to run tests at this time as well.
8. Upgrade the *old* system from V2R3 to V2R4.
9. Rerun the queries and the explains on the old system and look for trouble. Let the users run for 30 days or so, to see if any trouble pops up.
10. Sysinit the new system and install V2R4 on it.
11. Dump the old system and load it on the new hardware. Since the old & new systems are as close to identical as they can get, this should make the rehosting easier.
If I had severe time constraints, I'd do this:
1. Upgrade the *old* system to V2R4 and shake out any problems there (30 days of test).
2. Rehost to the new system.
I think it's imperative to upgrade the old system in place before you perturb your user base by rehosting them.
I think that compared to V2R3.0.3, V2R4.1.2 will be an improvement, but there's always a chance that you'll find a problem. Our site is particularly prone to bug finding because we run 14 completely distinct & independent applications that do not share data or data architects or even DBAs. And we've seen a lot of bugs since going from V2R4.0.2 to V2R4.1.0/V2R4.1.2, mostly because there was a lot of optimizer performance code added to V2R4.1.
I've opened about 20 problems since upgrading to V2R4.1.0; half are bugs, and half are query performance changes (i.e. it ran fast yesterday & now it doesn't). Most of the bugs are fixed in V2R18.104.22.168, which we're rolling through our systems now, but the performance issues don't usually get addressed as quickly.
On the whole, I'd say move forward, especially if you can use the long test scenario.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 23 Jun 2019|