topic Re: SDEGDBREPAIR help in Data Management Questions

SDEGDBREPAIR help

AbhijeetKulkarni — Sat, 04 May 2013 21:09:55 GMT

hi,
I am running sdegdbrepair -o diagnose_tables daily to know the status of table. One day I found below result.

ESRI ArcSDE Server Repair Utility Wed Apr 24 06:56:42 2013
----------------------------------------------------------------
35235 rows referencing nonexistent states found in User1.A172 (User1.Layer1)
27678 rows referencing nonexistent states found in User1.D172 (User1.Layer1)
15 rows referencing nonexistent states found in User1.A231 (User1.Layer2)
Diagnose Tables: 145 multiversioned tables examined,
2 multiversioned tables had orphaned, duplicate, missing or redundant rows.

I tried running sdegdbrepair as below for first layer
sdegdbrepair -o repair_tables -d ORACLE11G -r User1.Layer1 -V ALL -u sde-adminusrname -p password -D databasename

and I got below error:
Error: Underlying DBMS error (-51).
Error: Unable to complete repairing orphaned rows.

I had ensured that no other user is working on this database and ensured to remove all existing locks also.

Can someone point me into right direction to resolve this?

Re: SDEGDBREPAIR help

MarcoBoeringa — Sun, 05 May 2013 08:28:52 GMT

According to this Help page, 51 is just a generic error code generated when ArcSDE doesn't recognize the DBMS error. Have you checked the logs as in the Help text?:

"Underlying DBMS error (-51)
An error was returned from the database that was not recognized by ArcSDE or the client application. Check the DBMS logs for more information."

It is probably a completely unsupported operation by ESRI, but since it only affects two layers and it seems to concern orphaned rows "referencing non-existent states", you might consider joining the SDE_states system table to the A and D tables (User1.A172 etc.) that have the orphaned rows. This will quickly tell you which rows are orphaned, as there will be no join results from the SDE_states table for those records in the A and D tables that are orphaned. You could than delete those, or maybe even better copy them first to another table for reference and examining to make sure nothing important is lost upon delete.

*** EDIT ***:
Only do the above if your Feature Classes do not participate in any geodatabase behavior (e.g. no relationship classes, topology, network dataset etc. defined), so Simple Feature layers only. Otherwise the layers and A and D tables may, or better said will, have relationships and dependencies on other tables and Feature Classes, and that may cause additional issues. Backup the database beforehand.

Re: SDEGDBREPAIR help

VinceAngelo — Sun, 05 May 2013 17:18:02 GMT

If tools indicate corruption of your geodatabase you should:
1) Immediately transfer as many of your incremental backups as possible to
permanent storage (something that won't be overwritten by future backups --
be careful not to corrupt the ability to restore to a future point in time).
2) Make a complete (snapshot) backup of the current database (in such a way
as to not prevent the ability to roll back -- see above)
3) Contact Esri Tech Support (these Forums are not Tech Support).

- V

Re: SDEGDBREPAIR help

MarcoBoeringa — Sun, 05 May 2013 18:15:28 GMT

3) Contact Esri Tech Support (these Forums are not Tech Support).

- V

Agree.

Marco