Archives of the TeradataForum

Message Posted: Tue, 12 Feb 2002 @ 13:52:14 GMT

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

WOW....! I have had similar concerns on archive and backup as our data volume grows. I have recently been roaming our halls asking how much data is too much data? I have recently started to ask our applications teams to review what we are doing with all this data .... did you ever wish that NCR database logging extended to the column level and not just the table level...? So you could see if people are using some of this data.... I have also asked NCR what they are doing about using things like SRDF and split mirror disk backups....

We run 8-9 archive backup jobs all backing up at the database level to backup a terabyte. I am lucky in that I get a good window on Sunday to shoot at all this data at once. We do not use journaling.... so we take full system copies. I would love to see a Partners Presentation on journaling and the effects it has on transaction processing and backup times.... We backup to the mainframe.... I did not like or get along well with an STK Silo so they sit and gather dust. I try to slice my Teradata box up into equal parts and backup by application and by parts to try and achieve a run of jobs that balance in time and size. We have always tried to be mindfull of what is on what tape.... things get backed up in alpha order. On Silo's ASF2 used to have a fastpath feature that was kind of like the index of what was on the tape and where it was. It saved alot of time in read-positioning before the actual restore started. This would be a wonderfull feature for mainframe or other silo product vendors to exploit for Teradata mainframe based backups. In one instance here we had a small non-volitale DB that alphabetically came at the end of the tape.... The restore took 5 hours to read-position and 10 minutes to restore....!

We use NCR Disaster Recovery services and we contract for a DR box that is alot smaller then our normal box here. So for DR we are faced with what I call a negative space migration. We take a much bigger catalog and restore it on a smaller box and DBC comes up with negative space.... The hardware configuration is different and this makes it more of a challenge to use "cluster" backups as the clusters are not the same on the DR box. Can you restore to systems with un-like clusters? Yes you can but it is a bit more challenging and time consuming that database backup restores on systems with un-like clusters.... With this said you are somewhat limited in your choice of backup types if you have a DR policy or plan that calls for a limited amount of recovery time for a critical application. For DR we create secondary copies of our backup tapes for offsite storage. We use ibm utility to create the second copy of the tape. In our case it has proven to save some Teradata system time.

If I had a system the size of yours .... And I am fastly approaching those numbers.... I would cluster large database/tables. Test running your backup jobs in parellel and serially until you find a balance. I have one system where I save a good amount of time running them two at a time instead of four across. I would run database backups on smaller tables being mindfull of critical tables and the alphabet. Are there any tables that greatly effect your business if they take a large amount of time to restore.... back them up seperately.... Try running with different logon priorities.... use high speed drives where applicable.... use no-empty database parms.... I have found Teradata-Archive to be an art and not so much a science. Do not be afraid to experiment and review your backup jobs frequently.

Good Luck....

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