02.04.2010, 02:01 | #16 |
Живёт в форуме
Регистрация: 12.01.2010
Имя: Дмитрий
Откуда: Санкт-Петербург
Автомобиль: Koleos DC
Возраст: 45
Сообщений: 826
Благодарности: 815/261
|
GERR, не хочу ставить под сомнение мнения Ваших друзей, но я бы так категоричен не был. Сколько копьев на этой ниве уже поломано... А сколько еще будет!
|
02.04.2010, 12:12 | #19 |
Живёт в форуме
Регистрация: 12.01.2010
Имя: Дмитрий
Откуда: Санкт-Петербург
Автомобиль: Koleos DC
Возраст: 45
Сообщений: 826
Благодарности: 815/261
|
Даже не предполагаю кого Вы называете героем...
Ну тогда по порядку: Для начала отрубил сервер от сети, и посмотрел на него в состоянии покоя - это чтоб отсечь системные сбои. Затем проверил диски на всевозможные ошибки и бэд-секторы - это чтоб отсечь проблемы с накопителями. Затем были отключены все не системные базы данных и подключен обратно к сети - это чтоб отсечь всяческие вирусняки или происки каких-нить конкурентов (вдруг кто специально наш сервер ложит... да-да паранойя всегда со мной ) После всего этого сервер ни разу даже не чихнул. Значит дело в каком-то криво написанном и работающим с SQL софтом. Этот вывод вызвал маленькое недоумение, поскольку весь софт в конторе, общающийся с сервером (не считая 1С, конечно), написан лично мной (или в команде со мной), и работает уже не один год. 1С тоже давно на нем прописалась. Семерка с 2006 года, восьмерка с октября 2008 года. По идее подобные косяки уже должны были бы велезти наружу. Ан нет... Поиски "преступного" приложения, которое могло бы вызвать столь масштабное действо с базой tempdb, решил искать так: отключались вообще все базы, а затем по одной подключались обратно и наблюдалась деятельность пользователей. Мне жутко повезло, что бухгалтера оказались самыми нахальными, и в первую очередь по одной были запущены базы для 1С v7.7. Сервер это пережил нормально (оно и понятно, все таки семерка мало чего делает непосредственно на сиквеле - в основном тока данные туда-сюда гоняет). Через полчаса была запущена база конфигурации ЗУП уже для 1С восьмерки. Тоже все прошло нормально. Еще через полчаса была запущена база для восьмерочной бухгалтерии. И вот оно - не прошло и пяти минут сервер уже стонал от бессилия и его инстинкт самосохранения остановил сервис с выше обозначенными сообщениях в логах. Личность преступника установлена. Дальше начались поиски "точки входа в косяк". Это оказалось самым геморройным делом. Поскольку пользователей куча, приходилось выяснять то, что-же кто делал в момент остановки сервера. Свелось это к банальному опросу юзеров, потому что одинэсовский журнал регистрации событий имеет маленькую, но очень неприятную, особенность - он регистрирует события уже по факту их происшествия. Все попытки действий не дошедшие до своего логического завершения там не фиксируются. На просьбу вспомнить свои манипуляции, естественно мало кто чего вразумительного отвечал, в основном - "Работала!" Поэтому опять-таки по одному пускались юзеры в базу и наблюдалась их активность. Так нашелся бухгалтер - виновник торжества. Маленькая ремарка: Платформа 1С восьмерки наконец-таки дала возможность почти полноценно работать с базами данных. Строить сложные запросы, в том числе и с использованием временных таблиц. Это очень удобно и эффективно, но в этом кроются и подводные камни. Наверно уже понятно зачем я эту ремарку вставил. Так вот определив документ, который вызывал крах (им оказался документ "Списание материалов из эксплуатации"), я внимательно стал смотреть чего-же в нем понаписали программисты 1С. Увидел множество запросов к базе с использованием тех самых временных таблиц в рамках одной процедуры. Еще ремарка: уж так устроена платформа, что уничтожение временных таблиц (а тем самым и очистка базы tempdb на SQL сервере) происходит после того, как все операторы процедуры будут выполнены (если их очистка не вызвана явно в теле процедуры). Как можно догадаться принудительно никто их не очищал, данные копились. В определенный момент достигался предел (хотя мне трудно представить, чего же там такого огромного было), по каким-то причинам база tempdb не могла увеличиться, сервер останавливался. Сил выяснять причины такого поведения SQL уже не было (шел 13-й час борьбы с проблемой, и дело близилось к полуночи ) - решением проблемы стало дробление документа на два. Резюмируя хочется верить, что это отдельно взятая беда SQL Server 2000, на ряду с ограничением на количество в 256 таблиц участвующих в одном запросе. Как не хотелось мне переходить на более современный сиквел, но по ходу дела придется. |
02.04.2010, 13:24 | #20 |
Мудрец
Регистрация: 19.02.2010
Имя: Kir
Откуда: SPB
Автомобиль: Koleos LP
Возраст: 48
Сообщений: 247
Благодарности: 39/19
|
Если полиси позволяют, то почему бы ине перейти? 2005 получше чем 2000. Так что ура апгрейду
__________________
Тише едешь - дальше будешь от того места куда едешь. |
02.04.2010, 14:02 | #21 |
Живёт в форуме
Регистрация: 12.01.2010
Имя: Дмитрий
Откуда: Санкт-Петербург
Автомобиль: Koleos DC
Возраст: 45
Сообщений: 826
Благодарности: 815/261
|
Kir, Да основным тормозом перехода была 1С семерка. Она официально не работает с 2005 сервером. Не говоря уже об 2008. А всяческого рода запилы (есть вариант правки нескольких dll из состава 1С) мне не очень по душе...
И потом при переходе (давно правда это было) с версии SQL 6.5 на версию 7.0 пришлось много чего править, из-за отличий в синтаксисе. Вроде бы с 2000 переход легче осуществляется, но кто обещаниям Билли верит!? |
Метки |
2000, server, sql, нужна, помощь |
Здесь присутствуют: 1 (Членов Клуба: 0 , гостей: 1) | |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Всякая-разная помощь | kotya | Взаимопомощь. Благотворительность. | 16 | 21.01.2014 15:37 |
SOS!!!НУЖНА ПОМОЩЬ РЕМОНТ!!!SOS | Деда Митя | Взаимопомощь. Благотворительность. | 7 | 18.07.2012 19:46 |
Очень нужна кровь и помощь девочке | Aleksey-F | Взаимопомощь. Благотворительность. | 11 | 12.07.2011 11:46 |
нужна помощь питерцев. | Qwert76 | Санкт-Петербург | 54 | 07.07.2010 17:32 |
SOS быстрая помощь | EvgenyET | Электрооборудование. | 4 | 28.02.2010 23:29 |