| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3139.1 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Thu Sep 26 1996 06:14 | 43 |
| 3139.2 | any ideas? | UKVMS3::SHISCOCK | stand and deliver | Mon Feb 10 1997 06:43 | 6 |
|
Does anyone know why so we can explain this to the customer?
many thanks,
Steve
|
| 3139.3 | | M5::LWILCOX | Chocolate in January!! | Mon Feb 10 1997 09:33 | 1 |
| Does a VMS DUMP of each of the backups help shed any light?
|
| 3139.4 | XOR redundancy blocks ? | ORAREP::HERON::GODFRIND | Oracle Rdb Engineering | Thu Feb 13 1997 07:37 | 8 |
| Well, on tape we do include additional XOR redundancy blocks for error
correction. How frequently they are written is controlled by the /GROUP_SIZE
qualifier. The default is device-dependent.
Try doing a backup to tape with /GROUP_SIZE set to 0 and see how big the
resulting file is.
/albert
|
| 3139.5 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Fri Feb 14 1997 11:22 | 3 |
| Thank-you Albert. That's the explanation - it made a big difference.
Louise.
|
| 3139.6 | | ORAREP::HERON::GODFRIND | Oracle Rdb Engineering | Fri Feb 14 1997 11:34 | 8 |
| > Thank-you Albert. That's the explanation - it made a big difference.
Good to hear this.
However, the customer should still let rmu write the XOR blocks (even if the
backup requires more tape space). It lets restore recover single bit errors.
/albert
|