Изправени пред един проблем, когато клиентите имат "специфични" характер на следващата грешка:

Следната грешка (и) са настъпили: оригиналното съобщение за грешка: I / O грешка (лош страница ID) открити по време на четене на офсет 0x00000010a5c000 в fileC: \ terrasoft \ Data \ terrasoftCRM 30x15 Rus.mdf

запазваме записа грешка. оригиналното съобщение за грешка: I / O грешка (лош страница ID) открити по време на четене на офсет 0x00000010a58000 в fileC: \ terrasoft \ Data \ terrasoftCRM 30x15 Rus.mdf

оригиналното съобщение за грешка: Не можах да намеря записа на индекс за RID "16f1d2207bc9455f408a6e73882fe163ff010000" в индекса на страница (1: 498 400), индекс ID 0, базата данни "TSCRM30". «Call Stack»

Тази грешка се появява, когато сървъра на базата данни неуспешна. За решаването на необходимостта да се изпълни скрипт на базата данни с помощта Запитване анализатор или Management Studio:

ALTER DATABASE SET single_user Nazvanie_bazy

DBCC CHECKDB ( "Nazvanie_bazy". Repair_allow_data_loss)

ALTER DATABASE SET multi_user Nazvanie_bazy

Има една малка забележка
DBCC CHECKDB с repair_allow_data_loss параметър
Това може да доведе до загуба на данни, а вероятно да наруши целостта на системата логически

препоръчва се
- използвате архивиране
- премиера
DBCC CHECKDB с repair_rebuild опцията и само - ако тази опция не работи (в най-краен случай, ако няма друг начин), а след това с repair_allow_data_loss на опцията

Също така сподели опита :)
Разбира се тези критични грешки не са просто така, и обикновено това се случва, когато някой променя данните в базата данни и в същото време. светлините, или някой натисна бутона за изключване на сървъра (има дори такива, които вместо сървъра с помощта на компютър, на част от персонала :)). Всичко би било добре, ако сървърът на базата данни е UPS, и обикновено не плащат, докато трипер от гръм. DBCC checkdb не винаги може да помогне, но, разбира се, и аз бях спестяване :) бих Но ако това се случи, този проблем се препоръчва да направите следното:
1. Опитайте се варианти с DBCC checkdb
2. Ако имате късмет, можете да създадете пълно копие на базата данни от архива или да инсталирате или SQL скриптове и да използвате помощната програма за импортиране / експортиране, на SSIS "излее" в новата база данни и. UPS сложи на сървъра, зададете автоматично архивиране с проверка и да живее в мир :)
3. Ако все още някои таблици не може да го възстанови, аз съм го дръпнете данни от тези таблици, използващи изберете най-добре. пакети и "излее" ги в чисто копие.
Може би имате късмет и можете да дръпнете повече :)