Ora-600 [kcbz_check_objd_typ] error handling, ora600

Ora-600 [kcbz_check_objd_typ] error handling, ora600
Basic Elements

Channel feedback, HIS software in the data storage, prompt ora-600 error, the specific error information is as follows:

[Microsoft] [ODBC driver forOracle] [Oracle] ORA-20999: ORA-00600: Internal error code, parameter: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], [], [], [], [], []

ORA-06512: In "ZLHIS. ZL_ERRORCENTER", line 73

ORA-06512: In "ZLHIS. ZL _ patient XX print _ UPDATE", line 231

ORA-06512: In line 1

This error cannot be skipped, resulting in service failure.

Step 1: Analyze 'stored process' as prompted'

Reasonable this prompt is relatively clear, according to experience judgment may be ZL _ patient XX print _ UPDATE may have problems, combined with ORA-06512 errors, try to reconstruct the process and synonyms, after the above operations are performed, the problem persists.

Step 2: Analyze ora-600 errors

Then analyze the ORA-600 [kcbz_check_objd_typ] error, the error according to Baidu's explanation is because the Oracle checks the data block in the memory, it is found that the object number on the data block is wrong, this error prompt is thrown to further analyze the problem and find the error thrown when accessing the [patient XX print] table. We analyze the table separately, when we perform a full table query on the table, a ora-08103 error is prompted, but if only some tables are queried, the query is normal.

However, this object exists as follows:

Then we checked the structure of the table and found that the index of the table was BIN $ with a similar name, proving that the table was restored through flash back, here we finally located the problem.

The root cause of the problem is that the operator accidentally dropped the patient care print table and then restored it with a flash. However, for some reason, the data may be restored, however, the contents of the database dictionary table are incorrect (or do not match). As a result, the database prompts an error when performing any operations on the table, if we collect statistical information for ZLHIS users, we will also receive the following prompt:

Step 1: Rename the error table and create a new table with the same name.

Rename the [patient XX print] Table, create a new [patient XX print] Table, and insert the data into the new table using the insert statement, here, we should note that because there is a problem with accessing the old table, we must use the circular insert method, as shown below:

L rename a table

Rename patient XX print to patient XX print _ Original

L create a new table first

Create table patient XX print as select * from patient XX print _ Original where 1 = 2

/

Step 2: insert data from the original table to the new table

During insertion, we cannot access the original table through full table scan, but fortunately, we can access ROWID through full table, and we will create a table to keep the ROWID of the original table, insert the data to the new table one by matching the ROWID, as shown in the following figure.

L create a table that saves rowid first

Create table patient XX print _ rowid asselect rowed from patient XX print _ Original

L insert data one by one

Begin
For cursor_rowid in (select rrowid from patient XX print _ rowid) loop
Begin
Insert into patient XX print select * from patient XX print _ Original where rowid = CHARTOROWID (cursir_rowid.rrowid );
Commit;
End;
End loop;
End;
/

After the preceding operations, nearly 30 records cannot be transferred to the new table, but this does not affect the usage.