Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Crimean
Glory
Crimean
Glory
Ну так файлим как багу!
Что именно ? Ручное удаление из sysobjects ?


я бы не был столь категоричен
у меня фигня в syscomments
РУКАМИ _ЭТО_ точно не делали
ошибок в логах не найдено

Предложи другой способ воспроизводства бага


вот так сходу - не предложу

По-моему, мы опять начинаем растекаться мыслью по древу.
Для заявки на баг нужна воспроизводимая ситуация.
Ручное удаление записи из системной таблицы по-моему не может служить основанием для бага. Можно лишь просить об пересмотре алгоритма работы dbcc checkdd или расширении функционала средств диагностики.
29 дек 05, 17:37    [2221947]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Glory wrote:
> По-моему, мы опять начинаем растекаться мыслью по древу.
> Для заявки на баг нужна воспроизводимая ситуация.
> Ручное удаление записи из системной таблицы по-моему не может служить
> основанием для бага. Можно лишь просить об пересмотре алгоритма работы
> dbcc checkdd или расширении функционала средств диагностики.
дык об этом, вроде, и речь... чтобы ловить расхождения между индексами и
объектами....

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

29 дек 05, 17:46    [2221983]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
locky

Glory wrote:
> По-моему, мы опять начинаем растекаться мыслью по древу.
> Для заявки на баг нужна воспроизводимая ситуация.
> Ручное удаление записи из системной таблицы по-моему не может служить
> основанием для бага. Можно лишь просить об пересмотре алгоритма работы
> dbcc checkdd или расширении функционала средств диагностики.
дык об этом, вроде, и речь... чтобы ловить расхождения между индексами и
объектами....


Ну так это и есть разница между багом и пожеланием. :(
Первое все же быстрее исправляется
29 дек 05, 17:49    [2221991]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
Crimean

в свое время у меня была хорошая беседа с господами из MS.
у меня был битый IDE винт. я знал, что он битый. однако в логах временами было чисто. то есть после чистки логов можно было неделю жить с чистыми логами. на этот диск я бакапился. каждый день. бакапы делались на ура. restore verifyonly проходило тоже на ура. файлы копировались. но потом базы с этих бакапов не ресторились. с жуткими мессагами.
в итоге у меня на то время была ситуация с чистыми логами, чистыми бакапами и невозможностью рестора. да - бакапишься на другой диск и все ок, все ресторится. но - диагностики-то никакой! после этого мне и посоветовали после бакапа ресториться, потом делать dbcc checkdb и только после этого считать, что с бакапом все ок. мило, правда?


А как еще-то? Тут господа из МС правы на все сто - бэкапы (ленты, диски всех мастей, сетевые устройства) непременно надо тестировать в полном объеме: восстановление, проверка целостности, проверка работы приложения. Делается это один раз при внедрении системы а потом регулярно. Минимум раз в квартал, если есть возможность - чаще. Стандартная техника disaster recovery testing. Заодно и админы тренируются.

И заметьте, так со всеми DBMS, не только с MSSQL.
29 дек 05, 17:56    [2222023]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Шкшыр скуфь
Crimean

в свое время у меня была хорошая беседа с господами из MS.
у меня был битый IDE винт. я знал, что он битый. однако в логах временами было чисто. то есть после чистки логов можно было неделю жить с чистыми логами. на этот диск я бакапился. каждый день. бакапы делались на ура. restore verifyonly проходило тоже на ура. файлы копировались. но потом базы с этих бакапов не ресторились. с жуткими мессагами.
в итоге у меня на то время была ситуация с чистыми логами, чистыми бакапами и невозможностью рестора. да - бакапишься на другой диск и все ок, все ресторится. но - диагностики-то никакой! после этого мне и посоветовали после бакапа ресториться, потом делать dbcc checkdb и только после этого считать, что с бакапом все ок. мило, правда?


А как еще-то? Тут господа из МС правы на все сто - бэкапы (ленты, диски всех мастей, сетевые устройства) непременно надо тестировать в полном объеме: восстановление, проверка целостности, проверка работы приложения. Делается это один раз при внедрении системы а потом регулярно. Минимум раз в квартал, если есть возможность - чаще. Стандартная техника disaster recovery testing. Заодно и админы тренируются.

И заметьте, так со всеми DBMS, не только с MSSQL.


в _этой_ ситуации мне бы очень хотелось получить диагностику на этапе формирования резервной копии.
29 дек 05, 18:15    [2222086]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Glory wrote:
> locky
>
> Glory wrote:
> > По-моему, мы опять начинаем растекаться мыслью по древу.
> > Для заявки на баг нужна воспроизводимая ситуация.
> > Ручное удаление записи из системной таблицы по-моему не может служить
> > основанием для бага. Можно лишь просить об пересмотре алгоритма работы
> > dbcc checkdd или расширении функционала средств диагностики.
> дык об этом, вроде, и речь... чтобы ловить расхождения между индексами и
> объектами....
>
>
> Ну так это и есть разница между багом и пожеланием. :(
> Первое все же быстрее исправляется
как по мне - дык это баг в dbcc. Ведь налицо нарушение структуры базы, а
оно ево не ловит.

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

29 дек 05, 18:31    [2222106]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
locky

Glory wrote:
> locky
>
> Glory wrote:
> > По-моему, мы опять начинаем растекаться мыслью по древу.
> > Для заявки на баг нужна воспроизводимая ситуация.
> > Ручное удаление записи из системной таблицы по-моему не может служить
> > основанием для бага. Можно лишь просить об пересмотре алгоритма работы
> > dbcc checkdd или расширении функционала средств диагностики.
> дык об этом, вроде, и речь... чтобы ловить расхождения между индексами и
> объектами....
>
>
> Ну так это и есть разница между багом и пожеланием. :(
> Первое все же быстрее исправляется
как по мне - дык это баг в dbcc. Ведь налицо нарушение структуры базы, а
оно ево не ловит.


Гы. Ручная правка системных таблиц это чей баг ? :)
Ибо иным способом я пока данную ситуацию воспроизвести не могу.
29 дек 05, 18:34    [2222108]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
Crimean


в _этой_ ситуации мне бы очень хотелось получить диагностику на этапе формирования резервной копии.


Невозможно в принципе. Вы даете команду устройству: запиши на какую-то поверхность три числа: 100 200 300. Устройство внутри себя числа эти корежит, записывает, скажем, 400 500 800, а возвращает результат выполнения "записал успешно". И контрольная сумма совпадет, и все-все. Только вот чиселки 400 500 800 вам душу не греют.
RESTORE VERIFYONLY читает: 400 500 800, но для него цифры смысла не имеют, он лишь проверяет их читабельность - они читаются!
Проверить может лишь DBCC CHECKDB ну или при реальном восстановлении, когда надо структуру создавать на основе поступающих из бэкапа данных, а там уже такая фигня...
29 дек 05, 18:36    [2222110]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Шкшыр скуфь
Crimean


в _этой_ ситуации мне бы очень хотелось получить диагностику на этапе формирования резервной копии.


Невозможно в принципе. Вы даете команду устройству: запиши на какую-то поверхность три числа: 100 200 300. Устройство внутри себя числа эти корежит, записывает, скажем, 400 500 800, а возвращает результат выполнения "записал успешно". И контрольная сумма совпадет, и все-все. Только вот чиселки 400 500 800 вам душу не греют.
RESTORE VERIFYONLY читает: 400 500 800, но для него цифры смысла не имеют, он лишь проверяет их читабельность - они читаются!
Проверить может лишь DBCC CHECKDB ну или при реальном восстановлении, когда надо структуру создавать на основе поступающих из бэкапа данных, а там уже такая фигня...


уууу, как все плохо-то.....
скажем, при бакапировании можно считать контрольную сумму.
и писать ее в заголовок.
и если я прочитал потом 400 500 800 вместо 100 200 300, то контрольная сумма точно не сойдется ну никак
29 дек 05, 18:48    [2222136]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
Crimean
Шкшыр скуфь
Crimean


в _этой_ ситуации мне бы очень хотелось получить диагностику на этапе формирования резервной копии.


Невозможно в принципе. Вы даете команду устройству: запиши на какую-то поверхность три числа: 100 200 300. Устройство внутри себя числа эти корежит, записывает, скажем, 400 500 800, а возвращает результат выполнения "записал успешно". И контрольная сумма совпадет, и все-все. Только вот чиселки 400 500 800 вам душу не греют.
RESTORE VERIFYONLY читает: 400 500 800, но для него цифры смысла не имеют, он лишь проверяет их читабельность - они читаются!
Проверить может лишь DBCC CHECKDB ну или при реальном восстановлении, когда надо структуру создавать на основе поступающих из бэкапа данных, а там уже такая фигня...


уууу, как все плохо-то.....
скажем, при бакапировании можно считать контрольную сумму.
и писать ее в заголовок.
и если я прочитал потом 400 500 800 вместо 100 200 300, то контрольная сумма точно не сойдется ну никак


Как же ее читать, если лента уже уехала, назад что ли все время отматывать?
Но даже и при бэкапе на диски этого не делают из соображений производительности.
MSSQL даже в базе и то контрольную сумму не считает. В оракле такая функция есть, но все, кого я знаю, ее отключили - перфоманс страдает.
29 дек 05, 19:20    [2222176]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Незнаю.. скока не мудохался воспроизвести могу тока колупнув сис. таблицы, таки правда не перестройка не реорганизция успеха не дают.

Причем даже указав имя "прибитого" индекса, все DBCC прохавали его на ура :(
-------------------------------------
Jedem Das Seine
29 дек 05, 20:17    [2222230]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Maxx
Незнаю.. скока не мудохался воспроизвести могу тока колупнув сис. таблицы, таки правда не перестройка не реорганизция успеха не дают.

Причем даже указав имя "прибитого" индекса, все DBCC прохавали его на ура :(
-------------------------------------
Jedem Das Seine


большинство серьезных багов воспроизвести потом не получается
29 дек 05, 21:51    [2222343]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
ChA
Member

Откуда: Москва
Сообщений: 10989
не зарегистрирован
Cha. Верить или не верить - это Ваши проблемы, то, что у Вас эта ситуация не встречалась аргумент слабый. Я думаю, у Вас не встречалось 99% багов, которые фиксятся в каждом сервис паке. А ситуация реальная, не придуманная. То, что прошло ее обсуждение, я считаю лично для себя, и для многих читавших очень полезным.
Ну, во-первых, это Вы у меня спросили, почему трудно поверить, я ответил, и это не моя проблема, что ответ Вам не понравились.
Во-вторых, у меня нет проблем, они есть у Вас. И проблемы серьезные, которые говорят о нарушении целостности БД, причем Glory повторил ситуацию только непосредственным редактированием системных таблиц. Поэтому есть сильное подозрение, что Вы вручную исправляли то, что также вручную кто-то нарушил. Вы столкнулись с проблемой, нашли ее решение, честь Вам и хвала, но, IMHO, единственная польза из этого обсуждения - очередное подтверждение, что прямое редактирование системных объектов не рекомендуется.
Кстати, не забудьте таки снести "висячие" статистики. :) А еще лучше - сделать экспорт структуры и данных в новую БД, мало ли какие еще артефакты у Вас обнаружаться позже.

Удачи.
29 дек 05, 23:10    [2222413]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 17723
не по сути проблемы, а по обсуждению

>Вы столкнулись с проблемой, нашли ее решение, честь Вам и хвала,

я бы несколько поправил, хвалить нада не только за то что решил проблему, а еще и выложил это на обозрение.
у 99,99% это не встретится, а 0.01% это может очень помочь.
ведь не известно какой спец создавал-внедрял базу, может быть в его положении поправить системные таблицы было единственным выходом?
ведь 3 года работало, и проработало бы еще...

есть байка о том, что одним ударом молотка починили одну дорогостоющую машину, которую до этого никто не мог исправить. может предложенное решение и есть тот единственный удар молотка?
29 дек 05, 23:40    [2222433]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
ItDeveloper
Member

Откуда:
Сообщений: 33
Шкшыр скуфь
Александр Гладченко
не зарегистрирован

2) DBCC checkdb не отслеживает эту ситуацию, чего в общем-то не должно быть. То есть буквально сообщается "в базе все в порядке".


А почему Вы не использовали предназначенную именно для этого команду: DBCC CHECKTABLE ?
Проверка БД в этом случае и не должна была ничего сообщить...


не согласен. Если все _действительно_ так, как описывается (есть осиротевшие записи в sysindexes), то именно CHECKDB, и только она и могла бы об этом сообщить. И если она этого не делает, надо послать заявочку в МС. Правда, они могут сказать - а покажите на примере, как легальными средствами сделать так, что записи из sysobjects исчезают без надлежащей зачистки sysindexes. Предсттавить аппаратную аварию, приводящуу к такому эффекту я не в состоянии.


Заявочку в МС вполне можно было бы послать. Чтобы такой ситуации не произошло достаточно было бы вставить в таблицу sysindex foreign key на ID (код таблицы) ссылающийcя на таблицу Sysobjects (на primary key код таблицы).

Оправдания что из sysobjects можно удалить только вручную недобросовестным админом - это аналогично оправданию разработчика программы, который не создает констрейнты между справочниками и основными таблицами, только потому, что он считает что его программа не удаляет из справочника, не удалив предварительно из всех таблиц где есть коды (ссылки) на справочник, а пользователь программы сам виноват если он залез и удали из справочника значение ручками.

Если админу СУБД даны права на доступ к sysobjects, то господа из МС обязаны были позаботится о целостности ссылочности в между sysobjects и sysindex.
30 дек 05, 08:05    [2222660]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Andrey Ts
Member

Откуда: С-Пб
Сообщений: 516
ChA
но, IMHO, единственная польза из этого обсуждения - очередное подтверждение, что прямое редактирование системных объектов не рекомендуется.

Все-таки польза и в том, что теперь я (и надеюсь, не только) перестал думать, что DBCC CHECKDB - панацея от любых проблем в базе. Далеко не так, увы...
30 дек 05, 09:51    [2222819]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
А вот интересно - у автора наверняка и в других системных таблицах остались "висячие" данные. В syscolumns например
30 дек 05, 10:08    [2222859]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Crimean
Ну так файлим как багу!

P.S.А были бы ФК - вопросов бы было меньше.

Вполне возможно, что добавление в системные таблицы идет где-то на уровне ядра без проверки всяких FK constraint. Косвенное доказательство этому - несрабатывание триггеров на системных таблицах
30 дек 05, 10:11    [2222870]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Шкшыр скуфь
Как же ее читать, если лента уже уехала, назад что ли все время отматывать?
Но даже и при бэкапе на диски этого не делают из соображений производительности.
MSSQL даже в базе и то контрольную сумму не считает. В оракле такая функция есть, но все, кого я знаю, ее отключили - перфоманс страдает.

По моему мнению, тут должно быть какое-то взаимодействие с производителями. Чтобы оборудование имело режим записи с возвратом CRC записанного блока данных. контроллер RAID-5 ведь как-то же считает этот CRC для себя. Конечно производительность уменьшится, но все же с учетом времени необходимой для тестирования созданного бэкапа путем его восстановления будет меньше. Имхо
30 дек 05, 10:16    [2222889]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Шкшыр скуфь
Как же ее читать, если лента уже уехала, назад что ли все время отматывать?
Но даже и при бэкапе на диски этого не делают из соображений производительности.
MSSQL даже в базе и то контрольную сумму не считает. В оракле такая функция есть, но все, кого я знаю, ее отключили - перфоманс страдает.


а читать-то ее как раз на restore verifyonly!
чтобы это самое verifyonly чоть что-то проверяло

ЗЫ. про то, как эта команда работает, я в курсе
30 дек 05, 10:58    [2223041]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Приветствую всех еще раз!
По наводке Glory:
Glory
А вот интересно - у автора наверняка и в других системных таблицах остались "висячие" данные. В syscolumns например


был проведен беглый анализ системных таблиц, в результате написанного скрипта для проверки корректности ссылки на sysobjects и sysindexes были обнаружены висячие записи в следующих системных таблицах: syscolumns, sysdepends.
Текст скрипта приводится ниже:

--проверка целостности ссылок системных таблиц на Sysobjects и Sysindexes
select * from syscolumns where Id NOT In (Select Id from Sysobjects)
select * from syscomments where Id NOT In (Select Id from Sysobjects) 
select * from sysdepends where Id NOT In (Select Id from Sysobjects) OR (depId NOT In (Select Id from Sysobjects) and depId >0)
select * from sysforeignkeys where fkeyid NOT In (Select Id from Sysobjects) OR rkeyid NOT In (Select Id from Sysobjects) 
select * from sysindexes where Id NOT In (Select Id from Sysobjects)
select * from sysindexkeys where IndId NOT In (Select IndId from sysindexes)
select * from syspermissions where Id NOT In (Select Id from Sysobjects) 
select * from sysproperties where Id NOT In (Select Id from Sysobjects) --не найдена информация в BOL об этой системной таблице
select * from syspermissions where Id NOT In (Select Id from Sysobjects) 
select * from sysprotects where Id NOT In (Select Id from Sysobjects) 
select * from sysreferences where fkeyid NOT In (Select Id from Sysobjects) OR rkeyid NOT In (Select Id from Sysobjects) 

Таким образом, проблема действительно шире, и есть подозрение, что проверка целостности ссылок между системными таблицами не входит в число задач, которые возлагаются на пользовательские утилиты MS SQL.

Повторю, что не считаю это багом, естественно, всех предупреждают, но, тем не менее, если в принципе доступ к правке системных таблиц открыт, то такие ситуации вполне возможны, что и доказывает произошедший случай. Насчет причин - повторю, строить догадки трудно, потому что базы существуют уже около 6 лет, они последовательно мигрировали от версии 6.5. К тому же базы с момента создания используются очень интенсивно в плане создания/удаления таблиц (например, такой факт - в настоящее время в одной из баз количество таблиц - несколько десятков тысяч). Так что можно строить версии, но определенно что-то сказать - трудно. Основная версия, конечно - прямое вмешательство в таблицу sysobjects, не продуманное, но чем-то обусловленное. Словом, легкость поломки системных таблиц и отсутствие диагностики ошибок заставляет сделать вывод - модификация их не просто нежелательна, а крайне нежелательна, а и допустима только как крайняя мера для устранения критических сбоев и поломок.
С другой стороны, несколько лет назад все произошло, и ошибки никак не проявлялись. Только вот shrink упомянутый в начале темы, выявил проблему:) Промолчал бы, и не знал бы никто, что много лет назад что-то загадочное произошло в базе. Кстати, может возникнуть вопрос - а почему именно несколько лет назад, а не вчера? Тут помогли имена индексов - они содержали имена таблиц, к которым относились индексы, а по имени таблицы, в силу логики работающих задач, стало возможным очень примерно установить время возникновения проблемы - не менее 3 лет назад. Хотя можно было и точнее, но такой глубокий анализ требует времени и мотивации.
30 дек 05, 14:24    [2223996]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
ну допустим вот ето не бага вовсе

select * from sysdepends where Id NOT In (Select Id from Sysobjects) OR (depId NOT In (Select Id from Sysobjects) and depId >0)

Ето так "аккуратно" разработка и сопровождение БД ведется, т.к, что тут на MS кивать не стоит.
-------------------------------------
Jedem Das Seine
30 дек 05, 14:46    [2224083]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Maxx
ну допустим вот ето не бага вовсе

select * from sysdepends where Id NOT In (Select Id from Sysobjects) OR (depId NOT In (Select Id from Sysobjects) and depId >0)

Ето так "аккуратно" разработка и сопровождение БД ведется, т.к, что тут на MS кивать не стоит.
-------------------------------------
Jedem Das Seine


Не понял, поясните пожалуйста.
Во-первых, никто не говорит в этой теме о багах, надеюсь, Вы прочитали всю предысторию. Говорится о наличии проблемы, преодолении ее последствий и возможных причинах.
Во-вторых, если утверждение осознанное, привидите, пожалуйста пример действий по неаккуратной разработке и сопровождению БД, в результате чего могут появиться висячие записи в sysdepends? И почему именно в этой таблице, а не во всех остальных? Чем Вас привлек имеено запрос
select * from sysdepends where Id NOT In (Select Id from Sysobjects) OR (depId NOT In (Select Id from Sysobjects) and depId >0)
а не прочие 10 запросов?
30 дек 05, 14:56    [2224112]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
Crimean
Шкшыр скуфь
Как же ее читать, если лента уже уехала, назад что ли все время отматывать?
Но даже и при бэкапе на диски этого не делают из соображений производительности.
MSSQL даже в базе и то контрольную сумму не считает. В оракле такая функция есть, но все, кого я знаю, ее отключили - перфоманс страдает.


а читать-то ее как раз на restore verifyonly!
чтобы это самое verifyonly чоть что-то проверяло


Даже если эту идею и реализовать, это абсолютно не отменяет необходимости регулярной проверки бэкапов полным циклом: восстановление, проверка целостности, работа приложения.
Причины я в этой ветке излагать не буду, ибо и так уже отклонились.

Итак, тогда зачем париться?
И потом, диск, на который пишешь одно, а читается другое - это только вне рэйда может прокатить. Вне рэйдов важные вещи вообще не хранятся, так что о чем разговор?
30 дек 05, 15:01    [2224141]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
не зарегистрирован
Приветствую всех еще раз!
...
Таким образом, проблема действительно шире, и есть подозрение, что проверка целостности ссылок между системными таблицами не входит в число задач, которые возлагаются на пользовательские утилиты MS SQL.

... базы существуют уже около 6 лет, они последовательно мигрировали от версии 6.5.


Будет очень здорово, если Вы сделаете запрос в МС с описанием проблемы (упомяните что база тянется с версии 6.5), и предложите включить проверку ссылочной целостности системных таблиц в DBCC CHECKDB.
Это явная недоработка.

По моему опыту в последнее время очевидные баги фиксятся в МС довольно быстро и без бюрократии.

Но они могут попросить бэкап базы.
30 дек 05, 15:12    [2224172]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить