Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Glory
Интересные у вас постановки вопроса.
Давайте я скажу, что получил в вашем софте баг, но не скажу ни как собственно получил, ни на какой версии софта, ни на каком оборудовании.
Вот у вас лично хоть на одной базе запрос
select * from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'
выдал хоть какие-то результаты ?


Glory, похоже Вы уходите от рационального разговора.
Во-первых - никто ничего не скрывает. На конкретные вопросы был дан конкретный ответ - версия софта опубликована например, бэкапы, реиндексы, версия с использованием checktable - все обсужено. Сама проблема описана уже раз 5 наверное. Как она возникла - точно не известно, но она есть (вернее, уже была, хотя в бэкапе опять же сохранена, если есть необходимость - восстановлю и отвечу на доп.вопросы). Ну что Вы, думаете я выдумал все и теперь изголяюсь над гуру, что-то утаивая? Спрашивайте, какая информация Вам нужна? Ну несерьезно - какие флаги стоят на базе. Это уже похоже на поиск вслепую - авось найдется к чему придраться, и заявить - да как Вы до такой жизни дошли-то, батенька, читайте BOL и будете знать, как все решить, а Я мол знаю, как все сделать нормальными штатными средствами, но не скажу, на глупые вопросы не отвечаю.
29 дек 05, 15:39    [2221386]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
не зарегистрирован
Glory
Интересные у вас постановки вопроса.
Давайте я скажу, что получил в вашем софте баг, но не скажу ни как собственно получил, ни на какой версии софта, ни на каком оборудовании.
Вот у вас лично хоть на одной базе запрос
select * from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'
выдал хоть какие-то результаты ?


Glory, похоже Вы уходите от рационального разговора.

Я у себя ни на одном сервере не могу добиться описанной вами ситуации. Наверное у меня SQL какой-то багнутый
29 дек 05, 15:45    [2221409]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Crimean
кстати, вот очень интересно, а почему это в системных таблицах FOREIGN KEY не используются...


В случае с sysindexes - sysobjects constraint невозможен - в sysindexes есть автоматическая статистика, не привязанная к объектам - можно посмотреть,
select * from sysindexes where Id NOT In (Select Id from Sysobjects) AND name like '_wa%'
они включены в условие НЕ скрипта удаления повисших индексов
29 дек 05, 15:53    [2221454]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
select * from sysindexes where Id NOT In (Select Id from Sysobjects)

во всех 40 базах "(0 row(s) affected)"
29 дек 05, 15:55    [2221472]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Glory

Я у себя ни на одном сервере не могу добиться описанной вами ситуации.

А Вы хотите смоделировать эту ситуацию у себя на сервере? Или пытаетесь ее найти? Понятно, что ситуация нештатная, и в большинстве случаев не проявляется. Я бы не назвал это багом. Небольшим багом бы я назвал, что checkdb не фиксирует наличие такой ситуации.
29 дек 05, 16:00    [2221494]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Crimean
select * from sysindexes where Id NOT In (Select Id from Sysobjects)

во всех 40 базах "(0 row(s) affected)"


А вот это странно, вероятно, статистика ни по одной базе автоматически не создается, иначе должны были бы быть объекты статистики по полям с именами типа _WA_Sys_FieldName_7E1C876F не привязанные к объекту из sysobjects. Может быть, я чего-то не понимаю.
29 дек 05, 16:04    [2221523]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Мне удалось получить записи в sysindexes без записи sysobjects только когда я вручную удалил из sysobjects запись о таблице.
В этом случае dbcc checkdb и другие команды действительно не находят никаких ошибок в базе.
29 дек 05, 16:21    [2221607]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
ChA
Member

Откуда: Москва
Сообщений: 10989
не зарегистрирован
в sysindexes есть автоматическая статистика, не привязанная к объектам
Опаньки, а к чему же она тогда привязана ? Что-то у Вас там крупное сдохло, хотя действительно странно, что DBCC не отловил такие странности. Впрочем, гадать сложно, мы здесь, Вы там, и мы пытаемся верить Вам на слово, хотя это не очень удается :(
29 дек 05, 16:24    [2221626]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
не зарегистрирован

Совершенно согласен, пожалуй незачем было выдавать скрипт с влезанием в системные таблицы.

Ну вот и хорошо.

не зарегистрирован

Если можно, Шкшыр скуфь, смоделируйте поиск и устранение этой проблемы исключительно штатными средствами MS SQL.

ОГОВОРКА: предположим я ничего не знаю о сути проблемы, исходные данные - не шринкуется база.

Я по временам версии 7.0 помню была проблема с text/image полями. Первое, на что бы я подумал - ноги оттуда растут и проверил бы пообъектно занимаемые пространства.
(Кстати, нигде я не говорил, что системные таблички нельзя ИСПОЛЬЗОВАТЬ, говорил лишь, что не стоит их сгоряча ПРАВИТЬ.)

Скриптец у меня еще со старых времен завалялся:

use <SAPSID>
go
select
TEXT_reserved_MB,
TEXT_unused_MB,
TOTAL_reserved_MB,
Left(user_name(O.uid),5) as Owner,
object_name(O.id) as Name
from
  (select top 30
   id as Sid,
   reserved/128 as TEXT_reserved_MB,
   (reserved-used)/128 as TEXT_unused_MB
   from sysindexes
   where indid=255
   order by TEXT_reserved_MB desc) as S
inner join
  (select
   id as Tid,
   sum(reserved)/128 as TOTAL_reserved_MB
   from sysindexes
   where indid in (0,1,255)
   group by id) as T
on S.Sid = T.Tid
inner join sysobjects as O
on S.Sid = O.id
order by TEXT_reserved_MB desc


Если оно - экспорт/импорт пообъектно любым привычным способом.
Если не оно (что и есть в данном случае) - то я бы насоздавал новых файлов и опустошил бы существующие нешринкуемые поочередно с помощью опции EMPTYFILE команды DBCC SHRINKFILE, а потом удалил бы их alter database ... remove file.
Этот метод довольно эффективно уплотняет данные.
Ни разу не доводилось видеть, что SHRINKFILE-EMPTYFILE не работает.

Кстати, если у Вас еще остался бэкап несжимаемой базы, можете испытать и донести до общественности результаты.
29 дек 05, 16:29    [2221655]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Glory
Мне удалось получить записи в sysindexes без записи sysobjects только когда я вручную удалил из sysobjects запись о таблице.
В этом случае dbcc checkdb и другие команды действительно не находят никаких ошибок в базе.


Вероятно, по каким-то причинам действительно таблицы были удалены из sysobjects руками. Не думаю что это однако было злонамеренное действие.
Все-таки фиксировать такое положение dbcc checkdb было бы полезно.
Думаю, что тема исчерпана. Повторю, не сочтите за провокацию, была реальная, наверное небольшая, но все же проблема. Жаль, что обсуждение приняло эмоциональный характер.
29 дек 05, 16:30    [2221660]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
не зарегистрирован
Glory
Мне удалось получить записи в sysindexes без записи sysobjects только когда я вручную удалил из sysobjects запись о таблице.
В этом случае dbcc checkdb и другие команды действительно не находят никаких ошибок в базе.


Вероятно, по каким-то причинам действительно таблицы были удалены из sysobjects руками. Не думаю что это однако было злонамеренное действие.
Все-таки фиксировать такое положение dbcc checkdb было бы полезно.

Это точно. Похоже там просто цикл по объектам из sysobjects.
29 дек 05, 16:33    [2221669]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
Александр Гладченко
не зарегистрирован

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


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


не согласен. Если все _действительно_ так, как описывается (есть осиротевшие записи в sysindexes), то именно CHECKDB, и только она и могла бы об этом сообщить. И если она этого не делает, надо послать заявочку в МС. Правда, они могут сказать - а покажите на примере, как легальными средствами сделать так, что записи из sysobjects исчезают без надлежащей зачистки sysindexes. Предсттавить аппаратную аварию, приводящуу к такому эффекту я не в состоянии.
29 дек 05, 16:35    [2221680]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
ChA
не зарегистрирован
в sysindexes есть автоматическая статистика, не привязанная к объектам
Опаньки, а к чему же она тогда привязана ? Что-то у Вас там крупное сдохло, хотя действительно странно, что DBCC не отловил такие странности. Впрочем, гадать сложно, мы здесь, Вы там, и мы пытаемся верить Вам на слово, хотя это не очень удается :(


Похоже, действительно, проблема и со статистикой... Она обязательно должна быть привязана к объекту из sysobjects? Кто-то может точно сказать?

Насчет не верить - а почему так трудно? Что я неправдоподобного сказал и зачем тогда весь разговор, не понимаю, где Вы нашли противоречие в моих словах?

Надо подумать, что делать с этой потерянной статистикой. Может быть, будут советы как поступить?
Отмечу в очередной раз, что dbcc checkdb регулярно рапортует, что все в порядке, реиндексация, оптимизация и все прочее идет, и проблем в общем-то до сих пор до и после удаления хвостов не замечено.
29 дек 05, 16:45    [2221722]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Похоже, действительно, проблема и со статистикой... Она обязательно должна быть привязана к объекту из sysobjects? Кто-то может точно сказать?
Должна-должна. Согласно официальной схеме данных для системных таблиц sysobjects и sysindexes имеют логическую связь parent-child
29 дек 05, 16:47    [2221740]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

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

P.S.А были бы ФК - вопросов бы было меньше.
29 дек 05, 16:48    [2221744]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
не зарегистрирован
Glory
Мне удалось получить записи в sysindexes без записи sysobjects только когда я вручную удалил из sysobjects запись о таблице.
В этом случае dbcc checkdb и другие команды действительно не находят никаких ошибок в базе.


Вероятно, по каким-то причинам действительно таблицы были удалены из sysobjects руками. Не думаю что это однако было злонамеренное действие.


Именно поэтому я и говорю общественности: руки прочь от правки системных файлов. Наверняка человек, когда-то залезший в sysobjects радостно потирал ручки и приговаривал: "вот я какой крутой, фигли мне ЕМ". А Незарегистрировавшийся потом расхлебывай.

не зарегистрирован

Все-таки фиксировать такое положение dbcc checkdb было бы полезно.

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

Откуда:
Сообщений: 104760
Ну так файлим как багу!
Что именно ? Ручное удаление из sysobjects ?
29 дек 05, 16:51    [2221761]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Всем спасибо, наверное, сегодня больше не смогу общаться. Если будут предложения, как поступить, напишите, пожалуйста.
29 дек 05, 16:56    [2221786]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
ChA
Member

Откуда: Москва
Сообщений: 10989
не зарегистрирован
Похоже, действительно, проблема и со статистикой... Она обязательно должна быть привязана к объекту из sysobjects? Кто-то может точно сказать?
Конечно проблема, статистика всегда привязана к таблицам, почитайте BOL на тему статистик, что это, и зачем. И если вдруг у Вас обнаружились "висячие" статистики, то можете смело их убивать, так же, как и "висячие" индексы.

не зарегистрирован
Насчет не верить - а почему так трудно?
Хотя бы потому, что общаюсь с MSSQL слишком давно, но таких "глюков" не встречал, если только кто-то сам ручками не нашалил. Слава Богу, почти всегда находился легальный способ, чтобы исправить проблемы, без правки системных таблиц.

не зарегистрирован
Отмечу в очередной раз, что dbcc checkdb регулярно рапортует, что все в порядке, реиндексация, оптимизация и все прочее идет, и проблем в общем-то до сих пор до и после удаления хвостов не замечено.
Вот это-то и странно, что не нашел, может разработчики расчитывали на то, что если уж человек вручную правит системные таблицы, то он понимает, что именно, зачем и возможные последствия ?
29 дек 05, 16:58    [2221799]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

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


я бы не был столь категоричен
у меня фигня в syscomments
РУКАМИ _ЭТО_ точно не делали
ошибок в логах не найдено
29 дек 05, 17:01    [2221811]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

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


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

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

Откуда:
Сообщений: 175
Glory
Предложи другой способ воспроизводства бага


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

Откуда:
Сообщений: 104760
Шкшыр скуфь
Glory
Предложи другой способ воспроизводства бага


толко что вынес запись об объекте из sysobjects не трогая sysindexes.
Не воспроизводится проблема в полном объеме.
База рапортуется как полная, место как занятое.

Это понятно. Crimean пишет про "РУКАМИ _ЭТО_ точно не делали"
29 дек 05, 17:32    [2221931]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

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


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

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


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

но!

в свое время у меня была хорошая беседа с господами из MS.
у меня был битый IDE винт. я знал, что он битый. однако в логах временами было чисто. то есть после чистки логов можно было неделю жить с чистыми логами. на этот диск я бакапился. каждый день. бакапы делались на ура. restore verifyonly проходило тоже на ура. файлы копировались. но потом базы с этих бакапов не ресторились. с жуткими мессагами.
в итоге у меня на то время была ситуация с чистыми логами, чистыми бакапами и невозможностью рестора. да - бакапишься на другой диск и все ок, все ресторится. но - диагностики-то никакой! после этого мне и посоветовали после бакапа ресториться, потом делать dbcc checkdb и только после этого считать, что с бакапом все ок. мило, правда?
29 дек 05, 17:32    [2221932]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
ChA
не зарегистрирован
Похоже, действительно, проблема и со статистикой... Она обязательно должна быть привязана к объекту из sysobjects? Кто-то может точно сказать?
Конечно проблема, статистика всегда привязана к таблицам, почитайте BOL на тему статистик, что это, и зачем. И если вдруг у Вас обнаружились "висячие" статистики, то можете смело их убивать, так же, как и "висячие" индексы.

не зарегистрирован
Насчет не верить - а почему так трудно?
Хотя бы потому, что общаюсь с MSSQL слишком давно, но таких "глюков" не встречал, если только кто-то сам ручками не нашалил. Слава Богу, почти всегда находился легальный способ, чтобы исправить проблемы, без правки системных таблиц.

не зарегистрирован
Отмечу в очередной раз, что dbcc checkdb регулярно рапортует, что все в порядке, реиндексация, оптимизация и все прочее идет, и проблем в общем-то до сих пор до и после удаления хвостов не замечено.
Вот это-то и странно, что не нашел, может разработчики расчитывали на то, что если уж человек вручную правит системные таблицы, то он понимает, что именно, зачем и возможные последствия ?


Я все-таки отвечу, Cha. Верить или не верить - это Ваши проблемы, то, что у Вас эта ситуация не встречалась аргумент слабый. Я думаю, у Вас не встречалось 99% багов, которые фиксятся в каждом сервис паке. А ситуация реальная, не придуманная. То, что прошло ее обсуждение, я считаю лично для себя, и для многих читавших очень полезным.
Остальные Ваши общие слова и пожелания к теме отношения не имеют. Не сомневаюсь, что многое я знаю хуже Вас, так же как уверен, что многое и Вы не знаете, и со многим не сталкивались. Зачем стесняться? Разработчики например SQL сервера не стесняются говорить что например в этой области я не специалист. Все мы учимся, советуемся, для этого очевидно и форум.
29 дек 05, 17:32    [2221936]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить