SQL databases are getting corrupt

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • herhutatmoo
    New Member
    • Mar 2015
    • 1

    SQL databases are getting corrupt

    Hi,

    I'm having problems with databases that are getting corrupted.

    I have a server that runs a SQL Anywhere 11 database. (the consolidated database).

    Beside that, we have about 15 remote databases that run on the laptops of my mobile workforces.

    To keep all databases in sync, I have setup a two-way server-to-laptop replication.

    For the replication process I use “SQL Remote”.

    The log file of the dbremote utility does NOT show any errors, the replication seems to be finished without any problems.

    But after this, it’s not possible anymore to connect to the database, because of the following assertion error:

    [Sybase][ODBC Driver][SQL Anywhere]Internal database error *** ERROR *** Assertion failed: 201501 (11.0.1.2376)
    Page 0x0:0x7182d1 for requested record not a table page -- transaction rolled back
    Error code=-301
    SQL state=HY000

    Can do some analyzing myself to see what exactly got broken in the database?

    Any help is appreciated.

    Thanks.
  • magnusforsberg
    New Member
    • Mar 2015
    • 1

    #2
    I’d try the procedure described below or third party tool such as Recovery Toolbox for SQL Server https://repairsql.recoverytoolbox.com/ if that doesn’t work and database is severely corrupted.

    There might be other options out there. This is something that worked for me once but there are no guarantees that it will work at all times.

    Stop SQL Server instance
    -> Copy MDF and LDF files to another location
    -> Delete original MDF and LDF files
    -> Start SQL Server instance again
    -> Create new database with exact same name and file names
    -> Stop SQL Server
    -> overwrite newly created MDF and LDF.

    After this your database should be back online. If it is then go ahead and put it into EMERGANCY mode and SINGLE USER mode.

    Finally go ahead and execute DBCC CHECKDB like this DBCC CHECKDB (databaseName, REPAIR_ALLOW_DA TA_LOSS) WITH NO_INFOMSGS
    If you can get to this and execute last command successfully you should be good. If not then your only options are restoring from backup and/or using third party tool.

    Comment

    Working...