22
Invalid OAM Page %ld. Found pstat=0x%x, object=%ld, database=%d, indid=%d.
Depending on on the cause, error 1142 can be either a serious error due to actual corruption in the database or a result of misusing a system function (data_pgs, reserved_pgs, rowcnt, or used_pgs). Error 1142 can occur during run time as well as during recovery (during Adaptive Server startup, load database, or load transaction).
The error can occur from incorrect use of any of the following system functions that retrieve information about allocation pages:
data_pgs (version 12.5.x) or data_pages (version 15.0 and later)
reserved_pgs (version 12.5.x) or reserved_pages (version 15.0 and later)
rowcnt (version 12.5.x) or row_count (version 15.0 and later)
used_pgs (version 12.5.x) or used_pages (version 15.0 and later)
For example, if you incorrectly type the following query using version 12.5:
1> use pubs2
2> go
1> select reserved_pgs (id, root) from
2> master..sysindexes
3> where id = <object_ID>("<table_name>")
4> go
error 1142 is raised because the reserved_pgs system
function attempted to retrieve an invalid OAM page. (Replacing root in
the above example with a correct OAM page, for example doampg,
would give expected results.)
If you get error 1142 and you did not use system functions across databases, this error is a sign of serious corruption in your database. To verify this, run dbcc tablealloc on the object or dbcc checkalloc on the database as discussed in “Incorrect OAM page entry in sysindexes”, step 3.
Adaptive Server uses OAM pages to track how space is allocated for Adaptive Server objects. Error 1142 occurs when Adaptive Server tries to retrieve an OAM page and the status of that page indicates that it is not an OAM page. It occurs with the following states:
State |
Meaning |
|---|---|
1 |
The status of the first OAM page indicated that it was not a valid OAM page. |
2 |
Adaptive Server encountered an invalid OAM page during recovery or during an undo or a redo of a truncate table command. |
3 |
Adaptive Server encountered an invalid OAM page while preparing to read and install an OAM page in the buffer cache. |
4 |
Adaptive Server encountered an invalid OAM page during deallocation of an object page. |
Recovery from this error depends on the cause. Follow the instructions below, depending on the error’s origin.
When you want to use the system functions specified in “Incorrect system function use” across databases, select the database to be accessed with a use database command, then run the query for the current database.
If error 1142 occurred during the threshold accounting phase of recovery, the database is marked “suspect” and the object referenced in the error message output is corrupted. To determine whether the error occurred during this phase of recovery, look in the error log to determine whether the error occurred immediately after recovery.
Messages like the following would appear:
00:00000:00001:2007/09/26 12:43:36.15 server Recovering database 'testdb'. 00:00000:00001:2007/09/26 12:43:36.27 server Redo pass of recovery has processed 6 committed and 2 aborted transactions. 00:00000:00001:2007/09/26 12:43:36.33 server Error: 1142, Severity: 22, State: 1 00:00000:00001:2007/09/26 12:43:36.33 server Invalid OAM Page 64. Found pstat=0x111, object=2, database=0, indid=0.
If error 1142 occurs after messages like these, perform the following steps to recover from the error. Otherwise, go to “Incorrect OAM page entry in sysindexes”.
Turn off threshold accounting for the database affected by the 1142 error so that it can complete recovery:
1> use master 2> go 1> sp_dboption <database_name>, "no free space acctg", true 2> go
Where <database_name> is the name of the database in the error message.
For the affected database, use the instructions in “Resetting a database’s “suspect” status” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery guide to reset the status. Shut down and restart the server to complete recovery.
The object named in the error message is still corrupted. To recover the data, follow the instructions in “How to rescue data from a corrupted table” in the chapter “Other Useful Tasks” in the most recent version of the of the Troubleshooting and Disaster Recovery guide to recover the data.
Be sure to perform step 3 before going to step 4. Otherwise,
the next time you restart Adaptive Server, the error will reoccur
in the database.
Turn threshold accounting back on for the database affected by the 1142 error:
1> use master 2> go 1> sp_dboption <database_name>, "no free space acctg", false 2> go 1> use <database_name> 2> go 1> checkpoint 2> go
Where <database_name> is the name of the database in the error message.
In this case, error 1142 is a serious error and may result in reading the wrong OAM page into the data cache and corrupting a buffer in the process.
Follow these steps to clear error 1142:
Use the procedure described in “Finding an object name from a page number” in the chapter “Other Useful Tasks” in the most recent version of the Troubleshooting and Disaster Recovery guide to get dbcc page output for the page specified in the 1142 output.
If the page status bits row has the value 0x8000, the page is a valid OAM page. If the value 0x8000 does not appear in the dbcc page output for the page status bits row, the page is not a valid OAM page and the object is corrupted.
If the object is not corrupted, call Sybase Technical
Support to determine why the 1142 error occurred.
If the corruption is on a user table’s index (object ID is 100 or greater and index ID is between 1 and 250), run dbcc checktable to verify that the data page linking is good. If dbcc checktable runs cleanly, dropping and re-creating the index should clear the corruption.Use sp_helpindex to list all indexes on the table, then rebuild all the affected nonclustered indexes using one of two methods: :
If index ID is between 1 and 250, drop and re-create each nonclustered index on the table.
or:
If a clustered index also exists on the table, drop and re-create it, which causes all nonclustered indexes to be automatically rebuilt. If your table is large, you may not have the space to do this (a rule of thumb is that 150 percent of your table size must be available).
If the corruption is not on an index page, run dbcc tablealloc or dbcc checkalloc on the corrupted object. The output should report OAM allocation errors. Try to fix the reported allocation errors by referring to the information in this guide.
If these instructions do not correct the error, or the
error persists, contact Sybase Technical Support.
Before calling Sybase Technical Support, have the information available that is listed in “Reporting errors”, including output from dbcc page for the corrupted page and dbcc tablealloc or dbcc checkalloc for the corrupted object.
All versions
