Tag Info

New answers tagged

2

It is possible to detect such errors using backup checksums. If you use the CHECKSUM option, then yes it should be found but only when using a RESTORE or RESTORE ... WITH VERIFYONLY. If you don't check it, you'll never know. But what do you do when an error is found? That depends on what is wrong and where it happened. The action to be taken first ...


0

Error: Last_SQL_Errno: 1594 Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. This error means that either the master log file is corrupted or the relay log file is corrupted. Before doing anything backup all your databases, logs, image servers, repeat, several times, and only continue at your own risk. First run "show ...


1

You can run a --repairDatabase for that node: mongod --repair --repairpath <repair_path> Keep in mind that the repair path should have at least as your data size free disk space. (if you have 100GB, the repair path should have at least 100GB free also. That should take care of problems of that sort. Also, in the future if anything of some sort ...


0

The easiest solution would be to install a new instance of SQL Server (preferably one newer than 2005 RTM, which isn't supported anymore). If you have recent and valid backups: restore your databases on the new instance. If you don't have recent and valid backups: copy over the other MDF/LDF files, attach them, cross your fingers and say 30 hail marys ...


4

the error is myfile.mdf is not a primary database file. It means the original database had more files. You need to attach all files, including the log (*.ldf) and secondary files. Usually these are named *.ndf but in your case they appear to had been named *.mdf, like the primary. It can also happen that you renamed files during your 'recovery'. If ...


2

Error message says mssqlsystemresource is not found.,you can try copying resource database mdf and ldf to its place from another sql server instance. Source version from which you will copy resource database mdf and ldf should be same as destination version Below link may help you in knowing how to check resource database version and location of resource ...


4

You should restore it from your backup (which you can do by right clicking on "Databases" and selecting restore database)


3

Have you tried REPAIR TABLE; or myisamchk --recover tbl_name http://dev.mysql.com/doc/refman/5.1/en/repair-table.html --EDIT-- As mentioned in the comments under your question, convert your tables to InnoDB tables which are transactional. This should help prevent corruptions in the future.


1

Msg 8928, Level 16, State 1, Line 1 Object ID 1326627769, index ID 1, partition ID 72057594048872448, alloc unit ID 72057594055557120 (type LOB data): Page (1:69965) There is corruption in your SQL Server database column is LOB and may have VRCHAR datatype. Index ID 1 indicated problem with Clustered index so I guess minimum repiar options repair ...


3

It continues to become suspect after. Please provide me the permanent solution. The permanent solution is to figure out WHY/WHAT is causing the database to go suspect. Is it a filter drivers, bad hardware, etc. We don't know and can't tell you, this is something you'll need to inspect on your own. You'll want to get your sysadmins involved as well. ...



Top 50 recent answers are included