Archives of the TeradataForum

Message Posted: Sun, 24 Aug 2003 @ 10:04:57 GMT

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

Hi,

Processing Overhead: Mloads and Bteq do get impacted by having journalling in place. From what I remember the sites that I orked with reckoned the elapsed time overhead was somewhere around 15%, whatever the number it was acceptable to them given what journalling then allowed them to do. One of the sites already used journalling (for normal recovery mechanisms) so they felt that they got this additional capability (DR) with no additional penalty for their production processing.

Restoring journals: use ARC to restore the journals and then roll-forward. On both syste the same database names, space imits and heirarchy was used so life was made simple in that respect.

Special considerations: treat DDL changes as a break-point in recovery, i.e. you can't roll-forward 'across' one. For instance, if you want to add or remove a secondary index from a table the basic process is

-- stop update processing against this table on the master system

-- take backup#1 (optional)

-- do the change

-- take backup#2

-- copy backup#2 to the slave system

-- start maintenance against this table on the master system

Any journal images created for this table on the master system up to backup#2 that haven't yet been applied to the slave system can be discarded.

This was our approach to handling table definition changes. You may find now that there are some ddl changes where you don't need this 'belt and braces' approach. The reason for this approach is because Teradata maintains an internal version number for each table. Most DDL changes will increment this value and the roll-forward operation checks that the journal image came matches the current version for the table in the dictionary.

An MVS image can be connected to multiple Teradata systems. In reality this means that the MVS system has multiple TDP's defined to it and they are connected to different Teradata systems. Each TDP needs a different tdpid (i.e. TDP0 and TDP1) and also a different hostid (i.e. 300 and 301) within the Teradata configuration.

Physically where those Teradata systems are located is nothing really to do with Teradata, that's an MVS 'thing'. Having said that, taking this approach you're into MVS Channel Extenders and (the last time I checked) there are only a couple that NCR have certified. Talk to your NCR rep for the latest info. Again, you only need these if the distance from your MVS system is more than the limit allowed for a standard IBM/ESCON channel connect. Again, I don't know what the limits are but check with your NCR rep. If you're using fibre channels (I think NCR now supports those) then the distance will be longer.

Cheers,

Dave

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