Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Проблема была простая и банальная, но, как назло, никак не хотела решаться. А именно: после shrink-а базы несмотря на большое наличие неиспользуемого места (space free) размер файла данных (не лога) оставался большим. (Space used намного меньше current size для файла данных). На форуме этот вопрос поднимался много раз, в большинстве случаев однако речь шла о лог-файле. То, что помогло другим в таких ситуациях оказалось бесполезным. Все возможные опции DBCC SHRINKDB и SHRINKFILE, чекпойнты и т.д. не помогли. Переливать все объекты в новую пустую базу по ряду причин не было приемлимо.

Проблема решилась неожиданно - в sysindexes присутствовали индексы для таблиц, которые были давно удалены. Причем DBCC CHECKDB не выдавало и не лечило никаких ошибок. При сжатии базы очевидно экстенты, распределенные этим индекcам, по какой-то причине, не переносились к началу файла.

Решение - не было придумано ничего лучшего, как удалить эти записи из sysindexes и затем запустить DBCC_CheckDb при этом аллокированные этим индексам экстенты были освобождены и после этого shrink файла прошел успешно.

USE db1
delete from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'
DBCC CHECKDB ('db1', REPAIR_ALLOW_DATA_LOSS)

db1 должна быть в режиме Single user
28 дек 05, 18:18    [2218183]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

Откуда:
Сообщений: 175
не зарегистрирован
Проблема была простая и банальная, но, как назло, никак не хотела решаться. А именно: после shrink-а базы несмотря на большое наличие неиспользуемого места (space free) размер файла данных (не лога) оставался большим. (Space used намного меньше current size для файла данных). На форуме этот вопрос поднимался много раз, в большинстве случаев однако речь шла о лог-файле. То, что помогло другим в таких ситуациях оказалось бесполезным. Все возможные опции DBCC SHRINKDB и SHRINKFILE, чекпойнты и т.д. не помогли. Переливать все объекты в новую пустую базу по ряду причин не было приемлимо.

Проблема решилась неожиданно - в sysindexes присутствовали индексы для таблиц, которые были давно удалены. Причем DBCC CHECKDB не выдавало и не лечило никаких ошибок. При сжатии базы очевидно экстенты, распределенные этим индекcам, по какой-то причине, не переносились к началу файла.

Решение - не было придумано ничего лучшего, как удалить эти записи из sysindexes и затем запустить DBCC_CheckDb при этом аллокированные этим индексам экстенты были освобождены и после этого shrink файла прошел успешно.

USE db1
delete from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'
DBCC CHECKDB ('db1', REPAIR_ALLOW_DATA_LOSS)

db1 должна быть в режиме Single user


Я немею!
Товарищи, вы поаккуратней балуйтесь с системными табличками!
Лучше всего - руки прочь от них без острой необходимости.
28 дек 05, 18:29    [2218219]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Конечно, без надобности лезть в системные таблицы никто не призывает. Особенно когда не представляется, что может за этим произойти. Проблема изложена вкратце, я сомневался вообще-то, давать ее здесь или нет. На форуме подобная тема в свое время зависла без ответа, сам по себе вопрос мне показался интересным - действительно, база не сжималась, хотя все что можно было сделано. Наверное мне скрипт не надо было давать, просто в общих словах описать проблему и причину, так бы было лучше.
В общем случае пожалуй скриптование всех объектов базы, создание новой пустой базы и заливка туда всех данных было бы более правильным решением.
28 дек 05, 18:57    [2218277]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
1) select @@version
2) что за записи "повисли" в sysindexes? если инфа утеряна, то ценность топика=0
28 дек 05, 20:57    [2218490]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
ItDeveloper
Member

Откуда:
Сообщений: 33
Шкшыр скуфь
не зарегистрирован
Проблема была простая и банальная, но, как назло, никак не хотела решаться. А именно: после shrink-а базы несмотря на большое наличие неиспользуемого места (space free) размер файла данных (не лога) оставался большим. (Space used намного меньше current size для файла данных). На форуме этот вопрос поднимался много раз, в большинстве случаев однако речь шла о лог-файле. То, что помогло другим в таких ситуациях оказалось бесполезным. Все возможные опции DBCC SHRINKDB и SHRINKFILE, чекпойнты и т.д. не помогли. Переливать все объекты в новую пустую базу по ряду причин не было приемлимо.

Проблема решилась неожиданно - в sysindexes присутствовали индексы для таблиц, которые были давно удалены. Причем DBCC CHECKDB не выдавало и не лечило никаких ошибок. При сжатии базы очевидно экстенты, распределенные этим индекcам, по какой-то причине, не переносились к началу файла.

Решение - не было придумано ничего лучшего, как удалить эти записи из sysindexes и затем запустить DBCC_CheckDb при этом аллокированные этим индексам экстенты были освобождены и после этого shrink файла прошел успешно.

USE db1
delete from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'
DBCC CHECKDB ('db1', REPAIR_ALLOW_DATA_LOSS)

db1 должна быть в режиме Single user


Я немею!
Товарищи, вы поаккуратней балуйтесь с системными табличками!
Лучше всего - руки прочь от них без острой необходимости.


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

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

У моего знакомого Oracle админа была специально написанная процедура - которая находила в Oracle хвосты (прописанные в системных таблицах записи на не существующие объекты БД) и удаляла неправильные записи - так вот все это нормально работало и считаю что это гораздо правильней, чем сидеть и копить глюки в БД и не вмешиваться.
29 дек 05, 09:57    [2219586]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

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

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

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

У моего знакомого Oracle админа была специально написанная процедура - которая находила в Oracle хвосты (прописанные в системных таблицах записи на не существующие объекты БД) и удаляла неправильные записи - так вот все это нормально работало и считаю что это гораздо правильней, чем сидеть и копить глюки в БД и не вмешиваться.

Мда. После вашего соскока на Oracle при неумении справиться с deadlock-ми в MSSQL мне искренне жаль ваших пользователей.
29 дек 05, 10:25    [2219697]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Crimean
1) select @@version
2) что за записи "повисли" в sysindexes? если инфа утеряна, то ценность топика=0


1) Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3790: )

2) Естественно, проверены "повисшие" записи в sysindexes. Повторю, было выяснено, что это - индексы (некластерные) таблиц, некогда (более 3 лет назад) существовавших в базе. Ясно, что потеря некластерного индекса, тем более, для несуществующей таблицы (а на мой взгляд, и для существующей) - не критическая ситуация и ни в коей мере не влияет на сохранность данных.
Так же естественно, что предварительно были сделаны бэкапы, а по окончании операций - проведены проверки базы данных на целостность.

На мой взгляд, полезная информация из этого топика такова:
1) В MS SQL 2000 в принципе возможна ситуация, когда нарушена целостность в связке "объект" - "индекс".
2) DBCC checkdb не отслеживает эту ситуацию, чего в общем-то не должно быть. То есть буквально сообщается "в базе все в порядке".
3) DBCC shrinkfile также молча пропускает обработку страниц, принадлежащих указанным "потерянным" индексам, оставляя их на местах, что приводит к странной проблеме "несжимаемости" практически пустого файла. Только при "проталкивании" проблемы дальше, dbcc обнаружил, что существуют экстенты, распределенные несуществующим объектам и освободил их. Повторю, после этого база сжалась успешно. (до сжатия пустого места в файле было около 90%).

Конечно, можно было жить и так, я не спорю, и три года, как оказывается, жили. Но я согласен с IT developerom - в принципе можно идти по пути нерешения проблем, пока они не создают безвыходных ситуаций, а можно пытаться их решать более-менее осмысленно. Если есть конкретные замечания по техническим моментам решения данной проблемы, то буду очень благодарен их выслушать.
29 дек 05, 10:46    [2219788]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Проверил у себя на десяти БД объемом от 2 до 80Gb. Ни на одной подобного явления не обнаружил.
select * from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'
29 дек 05, 11:36    [2220046]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
мя интересовали собственно сами записи из sysindexes
практически все поля их
может там было что интересное...
29 дек 05, 12:11    [2220229]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Вот итерестно реорганизацией и перестройкой индексова ваще никто не занимаеться что ли ?
-------------------------------------
Jedem Das Seine
29 дек 05, 12:28    [2220329]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Maxx
Вот итерестно реорганизацией и перестройкой индексова ваще никто не занимаеться что ли ?
-------------------------------------
Jedem Das Seine


а не факт, что помогло бы
29 дек 05, 12:35    [2220373]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Crimean
мя интересовали собственно сами записи из sysindexes
практически все поля их
может там было что интересное...


Да нет, обычные записи об индексах - поля все нормальные, заполненные реальной информацией - имя индеса, ссылка на IAM, и т.д. Все как положено, за исключением того, что id объекта указывал на несуществующий объект (записи с таким id не было в sysobjects). Уверен, что и физически все страницы у этих индексов без родителя были в порядке, в нормальной последовательности, распределены и связаны как положено. Повторю, странно, что dbcc checkdb не проверяет наличие таких "повисших" индексов. И опять же, shrink страницы таких объектов не трогает - очевидно, "пляшет" от того же sysobjects - если там нет объекта, то предполагается, что у него нет ни данных не индексов.



Prolog
Проверил у себя на десяти БД объемом от 2 до 80Gb. Ни на одной подобного явления не обнаружил.
select * from sysindexes where Id NOT In (Select Id from Sysobjects) AND name NOT like '_wa%'

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


Maxx
Вот итерестно реорганизацией и перестройкой индексова ваще никто не занимаеться что ли ?
-------------------------------------
Jedem Das Seine

Естественно, индексы регулярно автоматически проверяются и перестраиваются - все Ok, никаких проблем не проявлялось. Проблема была обнаружена при разбирательстве причин "несжимания" базы (именно файла данных), когда пустого места в нем было уже более 90 %. Конкретно - проводилось разбиение данных и индексов наиболее часто используемых таблиц по различным файловым группам, облегчалась группа Primary. После переноса все файлы базы были последовательно сжаты,и вот тут и проявилась проблема - файл данных группы pimary, значительно облегченный, не хотел сжиматься, в результате исследования причин и выявилась вышеописанная ситуация.
29 дек 05, 12:55    [2220490]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Шкшыр скуфь
Member

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

Я немею!
Товарищи, вы поаккуратней балуйтесь с системными табличками!
Лучше всего - руки прочь от них без острой необходимости.


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

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

У моего знакомого Oracle админа была специально написанная процедура - которая находила в Oracle хвосты (прописанные в системных таблицах записи на не существующие объекты БД) и удаляла неправильные записи - так вот все это нормально работало и считаю что это гораздо правильней, чем сидеть и копить глюки в БД и не вмешиваться.


Oracle - это раскрученная база, что не означает автоматически "была есть и будет САМОЙ ЛУЧШЕЙ БАЗОЙ В МИРЕ". Oracle имеет массу глюков и багов. Самый вопиющий из которых - небалансирование дерева индексов. Алгоритм автоматического балансирования на лету студенты, изучающие Computer Science, на первом-втором курсе проходят. Еще у оракла масса проблем с целостностью данных в определенных условиях. Поэтому я не впадаю в священный трепет, услышав "ORACLE".
Однако в Oracle есть и очень хорошие вещи, справедливости ради надо сказать.

Мне совершенно не жаль MS SQL-ных админов, не умеющих правильно курочить системные таблицы - в этом просто нет необходимости, все можно сделать штатными средствами. Мне больше жаль оракловцев, ВЫНУЖДЕННЫХ уметь это делать.

Почему я написал свой первый ответ на пост. Я считаю, что процентов девяносто людей, посещающих этот форум, не обладают достаточными знаниями, чтобы безопасно для базы править системные таблички. Многие из них никогда и не посещали админских курсов. То, что для автора очевидным является забэкапить базу перед опасным действием, далеко неочевидно для многих. Подтверждение тому - регулярно появляющиеся здесь топики "помогите спасти базу, бэкапа нет". Поэтому не только упомянуть, но и ПОДЧЕРКНУТЬ это надо было обязательно.
Опять таки, нет никакой инфы, что могло привести к такому перекосу, и какие именно попытки сжать базу были безуспешными?
Была ли база оригинально создана в 2000 или пережила ряд апгрейдов с 6.5? Какие флаги активны?

Так что, действительно, ценность топика стремится к нулю, а вред при неверном использовании этого метода реален.

Проверил свои базы, ничего подобного нет.

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

Откуда:
Сообщений: 33
Glory
ItDeveloper

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

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

У моего знакомого Oracle админа была специально написанная процедура - которая находила в Oracle хвосты (прописанные в системных таблицах записи на не существующие объекты БД) и удаляла неправильные записи - так вот все это нормально работало и считаю что это гораздо правильней, чем сидеть и копить глюки в БД и не вмешиваться.

Мда. После вашего соскока на Oracle при неумении справиться с deadlock-ми в MSSQL мне искренне жаль ваших пользователей.


Прежде чем жалеть моих пользователей вы бы своих бы сначала осчастливили MS SQL репликацией без deadlock-ов. И что за привычка флеймить в топике перекидывая обсуждение из соседнего топика. Glory если есть что то сказать по теме данного топика - буду рад поспорить. А мерятся кто круче, вы меня уж увольте, я тут не собираюсь устраивать религиозные войны MS SQL vs Oracle. Я по крайней мере пишу и на том и на другом, и когда мне нужно что либо реализовать на MS SQL я каких то комплексов не испытваю (что подозреваю нельзя сказать о вас)
29 дек 05, 13:40    [2220754]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

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

Прежде чем жалеть моих пользователей вы бы своих бы сначала осчастливили MS SQL репликацией без deadlock-ов. И что за привычка флеймить в топике перекидывая обсуждение из соседнего топика. Glory если есть что то сказать по теме данного топика - буду рад поспорить. А мерятся кто круче, вы меня уж увольте, я тут не собираюсь устраивать религиозные войны MS SQL vs Oracle. Я по крайней мере пишу и на том и на другом, и когда мне нужно что либо реализовать на MS SQL я каких то комплексов не испытваю (что подозреваю нельзя сказать о вас)

Не надо постить глупые советы. Которые к тому же в основном сводятся к тому, как все тоже самое прекрасно работает на Oracle.
29 дек 05, 13:44    [2220782]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Шкшыр скуфь
[quot ItDeveloper][quot Шкшыр скуфь]
очевидным является забэкапить базу перед опасным действием, далеко неочевидно для многих. Подтверждение тому - регулярно появляющиеся здесь топики "помогите спасти базу, бэкапа нет". Поэтому не только упомянуть, но и ПОДЧЕРКНУТЬ это надо было обязательно.
Опять таки, нет никакой инфы, что могло привести к такому перекосу, и какие именно попытки сжать базу были безуспешными?
Была ли база оригинально создана в 2000 или пережила ряд апгрейдов с 6.5? Какие флаги активны?

Так что, действительно, ценность топика стремится к нулю, а вред при неверном использовании этого метода реален.

Проверил свои базы, ничего подобного нет.

Приветы.


Совершенно согласен, пожалуй незачем было выдавать скрипт с влезанием в системные таблицы.
О причинах я вовсе не поднимал разговор, я с ними не разбирался. Есть некоторые, весьма туманные предположения. Я просто констатирую текущее положение. Опять же согласен, что для подавляющего большинства практического приложения эта тема не имеет, и с базой в этом плане все в порядке. Но я считаю, что в принципе такие ситуации помогают яснее понять некоторые вопросы. Кстати, по форуму я искал, когда разбирался - пара-тройка человек задавала именно подобные вопросы. Им никто вразумительно не ответил. Если не считать ответы - запускай shrinkfile, а если не получается, то ничего страшного - подумаешь - 10-20 гигов пустых - постепенно база мол заполнится, что, денег нет диск побольше купить. Поэтому-то меня и заинтересовало - когда сам нарвался - а в чем же собственно может быть причина. Считаю, что многие прочитали тему с интересом, так что утверждение, что ценность темы близка к нулю, не принимается.
Неприятно, что тема быстро перешла на личности, тем более удивительно, что со стороны тех людей, чьи познания в области MS SQL не вызывают сомнения.

Теперь, если можно, я на время прекращу рассказывать, хотя рассказано не все, как эта проблема решалась (в том числе и штатными средствами) и задам встречный вопрос. Если можно, Шкшыр скуфь, смоделируйте поиск и устранение этой проблемы исключительно штатными средствами MS SQL. Всю необходимую информацию (например, по интересующим Вас флагам) опубликую по запросу.
Предлагаю продолжать в спокойном тоне, без высказывания мнений о личности автора и оппонентов.
29 дек 05, 14:03    [2220900]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Александр Гладченко
Member

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

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


А почему Вы не использовали предназначенную именно для этого команду: DBCC CHECKTABLE ?
Проверка БД в этом случае и не должна была ничего сообщить...
29 дек 05, 14:07    [2220918]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
ItDeveloper
Member

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


Oracle - это раскрученная база, что не означает автоматически "была есть и будет САМОЙ ЛУЧШЕЙ БАЗОЙ В МИРЕ". Oracle имеет массу глюков и багов. Самый вопиющий из которых - небалансирование дерева индексов. Алгоритм автоматического балансирования на лету студенты, изучающие Computer Science, на первом-втором курсе проходят. Еще у оракла масса проблем с целостностью данных в определенных условиях. Поэтому я не впадаю в священный трепет, услышав "ORACLE".
Однако в Oracle есть и очень хорошие вещи, справедливости ради надо сказать.

Мне совершенно не жаль MS SQL-ных админов, не умеющих правильно курочить системные таблицы - в этом просто нет необходимости, все можно сделать штатными средствами. Мне больше жаль оракловцев, ВЫНУЖДЕННЫХ уметь это делать.

Почему я написал свой первый ответ на пост. Я считаю, что процентов девяносто людей, посещающих этот форум, не обладают достаточными знаниями, чтобы безопасно для базы править системные таблички. Многие из них никогда и не посещали админских курсов. То, что для автора очевидным является забэкапить базу перед опасным действием, далеко неочевидно для многих. Подтверждение тому - регулярно появляющиеся здесь топики "помогите спасти базу, бэкапа нет". Поэтому не только упомянуть, но и ПОДЧЕРКНУТЬ это надо было обязательно.
Опять таки, нет никакой инфы, что могло привести к такому перекосу, и какие именно попытки сжать базу были безуспешными?
Была ли база оригинально создана в 2000 или пережила ряд апгрейдов с 6.5? Какие флаги активны?

Так что, действительно, ценность топика стремится к нулю, а вред при неверном использовании этого метода реален.

Проверил свои базы, ничего подобного нет.

Приветы.


Ну вот как всегда - стоит сказать Оракл в MS SQL - ном топике, так сразу пойдут обвинения чуть ли не в мании величия :).

Немного поясню - я работаю с Oracle и MS SQl почти в одинаковой мере - смотря где на чем крутится и какие задачи. Никогда не кричал Oracle forever, да и не буду кричать.
Oracle - курсы я проходил, MS SQL - нет. Админиить приходится временами и ту базу и другую. Своим топиком константировал факт - что хороший админ должен хорошо знать системные таблицы и в случае обнаружения хвостов уметь зачищать их не важно в какой базе - причем должен уметь это делать не только выгружая мастером или еще чем то все данные из рабочей в пустую - т.к. иногда перегрузить большую базу проблематично (а проблема может выеденного яйца не стоить).

Я и написал - "если на MS SQL -ных курсах админов все обстоит иначе - то мне искрене жаль MS SQL -ных админов".


А Oracl-овых админов никто ручками не заставляет лазить в системные таблицы - не умеешь база и без этого проживет и не грохнется - просто Oracl-овских админов учат это делать и самое главное не боятся этого. В Oracle EM можно практически мышкой то же самое что и в MS SQL EM. Так что о вынужденности Oracl-овских админов лазить в системные таблицы это вы уж сильно погорячились.

Чему же учат MS SQL - ных админов я не знаю - но книги по администрированию Oracle и MS SQL концептуально отличаются и это меня всегда убивало, т.к. в том же MS SQL иногда хочется не только мышкой пощелкать, но и поглубже залезть, а литература как будто расчитана на чайников.
29 дек 05, 14:09    [2220927]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Александр Гладченко
не зарегистрирован

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


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


А какую таблицу я бы указал в качестве аргумента checktable?
И потом CheckDb последовательно проверяет все таблицы в том числе, то есть делает то же самое, что и checktable для одной таблицы.
29 дек 05, 14:16    [2220953]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Glory
Member

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

Теперь, если можно, я на время прекращу рассказывать, хотя рассказано не все, как эта проблема решалась (в том числе и штатными средствами) и задам встречный вопрос. Если можно, Шкшыр скуфь, смоделируйте поиск и устранение этой проблемы исключительно штатными средствами MS SQL. Всю необходимую информацию (например, по интересующим Вас флагам) опубликую по запросу.
Предлагаю продолжать в спокойном тоне, без высказывания мнений о личности автора и оппонентов.

Для начала хорошо было бы узнать, каким образом база была доведена до такого состояния. Вдруг это были чьи-то попытки вручную "починить" таблицу Sysobjects
29 дек 05, 14:33    [2221036]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Glory
Для начала хорошо было бы узнать, каким образом база была доведена до такого состояния. Вдруг это были чьи-то попытки вручную "починить" таблицу Sysobjects


Точно определить причину затруднительно. Теоретически может быть, причина и в этом. А может быть и нет. Я например не могу точно сказать, да и что это меняет? Мне не виноватых требовалось найти, а разобраться в существующем положении.
29 дек 05, 15:01    [2221226]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Glory
Для начала хорошо было бы узнать, каким образом база была доведена до такого состояния. Вдруг это были чьи-то попытки вручную "починить" таблицу Sysobjects


фух. а средств убедиться в том, что в базе "все ок" нет? или, как и в случае с бакапом, чтобы проверить целостность бакапа, надо его заресторить, потом сделать dbcc checkdb (официальная рекомендация от MS)?

а тут уже выясняется, что и checkdb тоже не все проверяет.

кстати, вот очень интересно, а почему это в системных таблицах FOREIGN KEY не используются...

P.S.у меня вот сейчас в одной из баз "побилась" syscomments. я сижу и голову ломаю - как. скажем, вместо raiserror( 654321, 16, 1, ... ) там стоит raiserror( jtr321, 16, 1, ... ). так что вопрос не праздный.
29 дек 05, 15:01    [2221228]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
не зарегистрирован
Guest
Так как насчет штатных средств? Интересно все же. Какое резюме? Не лазь в системные таблицы, а если залез кто-то до тебя, и тебе надо это исправить, то пользуйся штатными средствами, а какими - сам должен знать. Никто не подскажет больше?
29 дек 05, 15:16    [2221292]     Ответить | Цитировать Сообщить модератору
 Re: может кому пригодится - неординарная проблема со shrink-ом базы  [new]
Crimean
Member

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


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

Откуда:
Сообщений: 104760
Crimean
Glory
Для начала хорошо было бы узнать, каким образом база была доведена до такого состояния. Вдруг это были чьи-то попытки вручную "починить" таблицу Sysobjects


фух. а средств убедиться в том, что в базе "все ок" нет? или, как и в случае с бакапом, чтобы проверить целостность бакапа, надо его заресторить, потом сделать dbcc checkdb (официальная рекомендация от MS)?

а тут уже выясняется, что и checkdb тоже не все проверяет.

кстати, вот очень интересно, а почему это в системных таблицах FOREIGN KEY не используются...

P.S.у меня вот сейчас в одной из баз "побилась" syscomments. я сижу и голову ломаю - как. скажем, вместо raiserror( 654321, 16, 1, ... ) там стоит raiserror( jtr321, 16, 1, ... ). так что вопрос не праздный.

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