Thursday, April 6, 2017

Is it safe to drop old tables in DBC?



Question :

Is it safe to drop old tables in DBC?

Environment/Conditions/Configuration

TDBMS 15.10.01.04b

Answer

Data can be deleted, but do not drop the tables. They are required for restores and migration purposes.

Additional Information
Why are there old versions of dictionary tables ( _V2R6, _TD12, _TD13, _TD14 )?

Q1) Why are there old versions of dictionary tables in DBC?

A1) The old versions of the dictionary tables are there for ARC data migrations. ARC uses these table headers when performing a migration from a previous release of TD.There are two scenarios for these tables:

1) Major upgrades
During major upgrades, the existing dictionary tables have their names changed by tableinit during the first startup on the new major DBS release. The dictionary tables that get recreated by tableinit will have their table names appended with the previous major release. So an upgrade from V2R6 to TD12 would append "_V2R6" to some dictionary table names and then recreate the base dictionary table for that current release. Likewise, then same happens from TD12 to TD13; the tables get appended with "_TD12". Only the table name is being changed by tableinit. All the rows will remain in the old table until the cleanup script is run after the upgrade. When the cleanup script is run, it will only remove the rows from the tables. In this way, the table headers remain on the system.

2) Sysinit
During tableinit after a sysinit, the old versions of the dictionary tables are created as table headers only. For instance, if the system is sysinited at TD14; then tableinit will create the data dictionary tables as well as the required copies of the _TD12 and _TD13 dictionary tables.


Q2) Should the old versions be removed from the system?

A2) No. These tables are required for ARC migrations. If these tables are removed from the system, checktable will report errors and ARC migrations from previous releases will fail!

NOTE: These tables cannot be regenerated without support from the GSC and possibly Engineering. Do not drop the tables without consulting with the GSC DBS Team.


Q3) When will the old versions be removed from the system?

A3) The system will maintain the old dictionary tables for the previous 2 releases. During a major upgrade to TD14, the _V2R6 tables will be removed by the 0010 preconversion script. This will leave the _TD12 tables in place, and the tableinit during TD14 startup will create the _TD13 tables. In the case of these tables remaining after a major
upgrade, the rows will be deleted by the cleanup script that should be run some time after the major upgrade is complete. If rows are seen in these tables, then the cleanup script should be run to drop these rows. This will ensure that the table headers remain on the system, as is required.


Q4) What happens if the old versions are not properly removed by the major upgrade scripts?

A4) If the oldest version is not removed by the 0010 script during the preconversion step, then there will be checktable and scandisk errors seen on the next major release. These errors are innocuous and will NOT affect the system.

What does the post_upgrade_cleanup script do?

1) Deletes the contents of the tables that were renamed by tableinit during the upgrade.
In other words if the upgrade was from TD13 to TD14 all of the dictionary tables name {tablename}_TD13 would have their contents deleted.

The tables are not dropped as these tables and their definition are required for restores/migration purposes. The internal DBS code expects these tables to have a well defined and unique Table ID which is why these tables should never be dropped.
The appropriate _TDxx tables will be dropped during the next major upgrade during the 0010.a.pre_upg.pl processing.

2) Deletes field 8 of the table headers created during table conversion.
On an upgrade when the dictionary tables are converted the conversion has to be restartable.
This is achieved by adding a special restart Field 8 into the table header of these dictionary tables.
After the major upgrade is completed this field 8 causes checktable errors to be be generated.
The post_upgrade_cleanup script calls program called cnvdelfld8 which removes Field 8 from the table headers.

3) When will the old {dictionary_tablename}_TDxx tables be dropped from the system?
The appropriate _TDxx tables will be dropped during the next major upgrade during the 0010.a.pre_upg.pl processing. Since we support migrations from the previous 2 major TD releases there will always be two sets of _TDxx tables on the system at any one time.

No comments:

Post a Comment