Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
1.2.2
-
None
-
None
-
2um 2pm external memory
-
2020-3, 2020-4, 2020-5, 2020-6, 2020-7
Description
Customer had an issue where PM1 failed and DBROOT 1 got assigned to PM2. PM2 had DBROOT 1 and 2 assigned to it and PM2 was the ACTIVE PARENT PM.. When PM1 was fixed, customer moved DBROOT 1 back to PM1, which was the incorrect process to do. DBROOT 2 should have been moved to PM1. The ACTIVE PARENT should always have DBROOT 1 assigned since it contains the DBRM files.
A startsystem was performed which lead to the deletion of the DBRM files because of the incorrect assignment.
The startsystem needs to check that DBROOT 1 is correctly assigned before allow a startsystem to run.
Attachments
Activity
The state where a failed restoral leaving a PM without a dbroot assigned should no longer be reachable with failover fixes from another issue. mcsadmin also block manually moving dbroot1.
This is how they moved dbroot 1, they used the unassign and assign. That is why I opened this issue
I cannot manually move dbroot1 if you can find a way to do this and reproduce let me know. Otherwise I think we can close this.