on 08-19-2015 11:18 AM
Dear all,
we performed a remote homogenous System Copy MaxDB on Linux with Backup/Restore procedure. The "recover_start <medium> DATA AUTOIGNORE" succeeded with RC=0 (8-time parallel backup files).
When we try to start the Database with "db_online", the process won't terminate and the Database stays in state "ADMIN". KNLMSG doesn't get new entries, the last ones are:
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: DYNP_K51_LOCK_LIST | : 90543136 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK maxlocks | : 300000 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK items | : 902400 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK Regions | : | 24 |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK TransRegions | : | 8 |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK RegionGlob+Space : 3840 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK TransGlob | : | 768 |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK SupplyItemsPerRgn : | 100 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK SupplySize | : 230400 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK RowHash entries : 300000 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK TabHash entries : 60000 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK Row+Tab hash size :2880000 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK Trans entries | : 1776 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK trans_list size : 639360 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK TransPtrList | : 14208 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK TransHash entries : 1776 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK TransHash size | : 14208 | |
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK SupplyPoolSegments: 9000 | ||
Thread | 0x4A81 Task | 120 2015-08-19 11:10:40 | dynpool | 54003: LOCK SupplyPoolSize | : 86616000 |
"db_cons show task" shows one interesting task
T120 8 19073 User | 19035 IO Wait (R) | 10 | 45 | 54(r) |
--> what is he waiting for?
"param_checkall" says OK.
Any helpful hints will be greatly appreciated. The target Database Release is the same as in Source: 7.8.02.035 (we took the 7.8.02.031 installation package and patched it).
Kind regards,
Dirk
Hi Dirk,
Please attach diagpack.tgz file after execute below os command:
dbmcli -d <dbsid> -u control,<password> diag_pack
You can find diagpack.tgz from maxdb run directory afterwards.
Best regards,
James
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi James,
thanks for your effort, points will be rewarded!
We found that the log partitions between source and target system were different: The source system has 4 log volumes with 2 GB each in 1 partition. The target system also has 4 log volumes with 2 GB each but only log volume #1 (DISKL001) belonging to log partition #1 (other log volumes were sort of unattached). We fixed this by putting log volumes #2 to #4 into log partition #1 via param_directput.
After a new "db_activate recover <medium> data autoignore" the database finally came up!
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.