Results 1 to 4 of 4
  1. #1
    Join Date
    May 2009
    Posts
    43

    Unanswered: reference bit and page allocation errors

    Hi All,

    I am getting the below error message in my production database.
    ---------------------------------------------------------------------

    Table Corrupt: Extent id 3119664 on allocation pg# 3119616 has objid 8 and used
    bit on, but reference bit off.
    Msg 2540, Level 16, State 1:
    Table Corrupt: Page is allocated but not linked; check the following pages and
    ids: allocation pg#=26316248 extent id=3119616 logical pg#=3119672 object id on
    extent=3119672 (object name =
    Invalid pointer param number 5, pointer value
    0x00000008
    ) indid on extent=45866184
    ------------------------------------
    I have tried running the below commands but the problem is not solved.
    dbcc tablealloc(syslogs,full,fix)
    dbcc checkcatalog(dbname,"fix_spacebits")
    dbcc checkalloc(dbname,fix)

    Please help to resolve the issue.

    Thanks,
    Vineela

  2. #2
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    If you are administering Production, you need to understand what you are doing, what dbcc does, what the error is. Read the System Admin Guide. I will answer generically, not just the single error, in order for you to understand what you need to do overall:
    - you have a single "hard" error on a single table
    - there is no need to waste production cycles checking the catalog and the allocations of the entire db (once you have an error, just deal with the single table/error)
    - why exactly are you (a) checking and (b) attempting to fix, the table allocation of syslogs ?
    That is the transaction log; very active; you will get dbcc errors on it, soft as well as hard; they are of no consequence; the errors will be different each time (it is a very active table); and it is completely unnecessary to try to fix them.
    - if syslogs is not on its own discrete segment, you do not have a "Production" database by any stretch of the imagination, you can forget about checking it entriely

    Every Night, for every db, you should:
    1 checkcatalog
    2 checkdb
    3 checkalloc
    A more advanced (smaller maintenance window) method is to identify and check only the tables that have been substantially changed:
    2 checktable for changed tables only
    3 tablealloc for changed tables only

    Note that:
    a. if you run dbcc on an active (as opposed to inactive, at 2:00 am) database, it will give you "spurious" errors, because the pages it is inspecting are changing under its nose, while the inspection is going on. You need to filter out these errors and be alarmed only about real hard errors, that is, 25xx and 79xx only.
    b. syslogs on an active production db can be ignored (if there really was a hard error on syslogs, believe me you would hear about it immediately, via other means, because commit/rollbacks would fail; dump tran would fail).
    c. For those hard errors only, run checktable/tablealloc with the "fix" option on the single object only.
    d. Sure, for learning purposes, for verifying whether an error is spurious or not, you can checktable/tablealloc again ... if the error is in a different locaition/page, it is spurious; if it persists in the same location/page, it is not. Obviously hard errors do not move.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  3. #3
    Join Date
    May 2009
    Posts
    43
    Dear Derek,

    Thanks for the valuable information you provided. Before running the dump scripts we are running the dbcc commands on the database to chech the integrity. So in this case do we have to ignore this error. Because I am still getting the same errors
    ---------------------------------------------
    Msg 2540, Level 16, State 1:
    Procedure 'bu_miaes_producer_sp', Line 7:
    Table Corrupt: Page is allocated but not linked; check the following pages and
    ids: allocation pg#=26316248 extent id=18133504 logical pg#=18133728 object id
    on extent=18133735 (object name =
    Invalid pointer param number 5, pointer value
    0x00000008
    ) indid on extent=56286404
    Msg 2546, Level 16, State 1:
    Procedure 'bu_miaes_producer_sp', Line 7:
    Table Corrupt: Extent id 18133736 on allocation pg# 18133504 has objid 8 and
    used bit on, but reference bit off.
    ------------------------------------------------
    As I am getting this in production database, I will test the same in the devlopement environment with this tran dump whether I can recover the database or not.

    Please advice me for further.

    Regards,
    Vineela

  4. #4
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    Object Id 8 is syslogs. That is the Transaction Log. Read my post again. If you are getting errors on object id 8/syslogs/transaction log, ignore them, as explained. Notice the errors are in different, changing extents, as explained.

    What do you mean by "this tran dump" ?

    If you do not have the transaction log on a separate, discrete device to the data, you have a much bigger problem: the database is not recoverable (and you won't be able to "dump tran db_name to tran_dump_file" anyway). In that case post again.

    What do you get for: exec db_name..sp_helpdb ?
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •