Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Tue, 18 Feb 2003 @ 19:46:34 GMT


     
  <Prev Next>   <<First <Prev Next> Last>>  


Subj:   Re: Info on and migration to V2R5
 
From:   Glen Blood

I have been asked to provide a little more detail.

Since I am up to my neck in alligators and currently running a performance test, this too will be brief, but longer than the previous missive.

We are moving from a 51050 and a 5250 running V2R4.0 to a single 5350 running V2R5.0.0.3 (can we add any more complexities?).

We were unable to run V2R4.0 on the new box, therefore, we had choices between upgrading to V2R4.1 and V2R5 and decided to be guinea pigs.

This hasn't been a smooth transition - Previous (V2R2 -> v2r3, V2R3 -> v2r4, and the 5150 -> 5250) transitions were a lot smoother. Of course, there we only had one moving part at a time and waited until y'all had the bugs worked out..

My advice would be to plan for a lengthy transition with lots of detailed testing. Make sure that all of the correct versions of the utilities are available before you get started and wait for V2R5.0.0.5 to come out (NCR claims that this will fix most of our identified issues).

Some of the issues that we found:

- Developers had multiple nested derived tables with the same derived tablename and unspecified columns in the select. This was a strengthing of the SQL definition. We fixed the code. Either specifying column source or changing the derived tablenames seemed to work.

- Some multiple select unions had to be broken up into two queries. This one brought the entire system down and caused a restart. This is supposed to be fixed in V2R5.0.0.5. Not really sure what the key was. Maybe we hit one too many unions.

- Formatting a character string and casting it as a date didn't seem to work in a multiload. I had to add additional casting. Haven't had time to revisit this one or open an incident.

- Problems with merging coalesce and non character strings and concatenation. Lots of solutions but V2R4.0 code wouldn't work in V2R5.0. NCR has identified this as a DR.

- One query gave us invalid results. We have a workaround.

- Large CRASHDUMPS dumps.

- Lots of questions about performance.

- Derived tables can change execution plans drastically because of confusion between derived table column names and base table column names.

- Teradata Manager 5.0.1 's locking logger does not seem to work correctly with V2R5.0. It builds the table and will not run the report (SQL error). I pulled the results out of the table directly, but they look fishy, so I don't trust them.

- Some funky results with full database restores from a database with Join indices. Worked most of the time, but didn't work correctly in one case. Had to drop and rebuild the tables.

Wish us luck,

Glen



     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016