Падение сервера и крушение базы при редактировании SP

[WAIK]

Добрый день! Сразу скажу, что выход найден, но хочу разобраться.
Ситуация такая:
Сервер (Intel-w2003) FireBird последний из серии 1.5.
На сервере три БД (1,2,3) - все боевые. В одной (1) из них редактировал процедуру точнее две связанные процедуры - менял входные параметры (добавил два параметра в одну, скомпилякал, изменил вызов в другой...) В момент компиляции Ibexpert выпал с сообщением о недоступности БД (1). Реконект говорил о том что БД (1) занята.
Обратился на сервер и поглядел подключенных пользоватетелей к другой БД (2). Среди пользователей появился странный чиж - [SQL server] именно так в скобках. Естественно такого пользователя несуществует. Перезапуск сервера и пробные соединения показали что БД (2) и (1) имеют потерянные страницы. Причём (1) ещё работоспособна, а вот (2) вообще...только соединение и очень медленная работа. Стандартные операции восстановления не помогли, поэтому был поднят ночной бэкап и добавлено то что удалось вытащить из новых данных (после бэкапа работала 2 часа) ну и головная боль для пользователей.
Извинияюсь за длинну, но вот вопрос, что это за пользователь такой, откуда берётся и что делать в таких ситуациях? Может зря останавливал сервер?

[Dimitry Sibiryakov]

Sweep-ер это.
Воспроизвести такое чудо isql-скриптом сможешь?

[Merlin]

Сервер (Intel-w2003) FireBird последний из серии 1.5.
На сервере три БД (1,2,3) - все боевые. В одной (1) из них редактировал процедуру точнее две связанные процедуры - менял входные параметры (добавил два параметра в одну, скомпилякал, изменил вызов в другой...) В момент компиляции Ibexpert выпал с сообщением о недоступности БД (1).

За супер, а особо виндовый, ничего уверенно сказать не могу, но классика гарантированно валится на одновременном альтере процедуры с двух соединений. Чтоб валилась на просто альтере используемой - такого отродясь не помню. Единственно - могут быть нюансы вокруг момента коммитов при работе с метаданными.

Обратился на сервер и поглядел подключенных пользоватетелей к другой БД (2). Среди пользователей появился странный чиж - [SQL server] именно так в скобках. Естественно такого пользователя несуществует. Перезапуск сервера и пробные соединения показали что БД (2) и (1) имеют потерянные страницы.

Зря ты свипа завалил, вот это дело как раз рисковое. От потерянных страниц (orphan) базе вообще-то ни жарко ни холодно, на них можно смело забить.

Причём (1) ещё работоспособна, а вот (2) вообще...только соединение и очень медленная работа.

Но таки работа. Знач может и целая. А медленная - мусора накопил мегатонны. Разогнал бы юзеров на часок, свип в монополе прогнал и вперёд. Ну иди бакап без сборки мусора, рестор в другой файл с вербозом и если всё ОК - опять же вперёд.

Стандартные операции восстановления не помогли,

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

[WAIK]

Посыпаю пеплом голову... работаю уже много лет с FIreBird и IB и никогда не попадался такой пользователь... Наверное от того что заглядывать в список подключений не было особого смысла.
Наверное я все таки именно рестартом сервера и сломал базу... Буду знать!

Меня немного смутило что утром БД (2) была 1.8 Гб а после аварии уже 4.8ГБ Да ещё и неизвестный user подключен... Сервак, судя по логам, выпадал по AV и запускался гвардом, так что вполне рабочая БД(2) (которую вообще не альтерил никто т.к. это боевая рабочая база и днём никакие изменения не проводятся) могла крякнуться.

Стандартные приёмы это те про котрые в книжке (первое издание) написано в соотвествующей главе ... других способов не знаю. Если можно не буду их описывать.
На всякий случай запустил InterBaseFirstAID - несколько больших таблиц стали носить очень странные имена в виде черных квадратиков место букв + плюс список 4-5 полей из таблицы. Например NS1###ID#DSE#NAMEDSE, только вместо решётки те самые квадраты. Реально это была таблица с простым именем NS1. Вот и решил что бд крякнулась...

ЗЫ. но всё же как я мог упустить что это свипер.... всё из-за попыхов.. всё нужно быстрее...

ЗЫ2. Разогнать юзеров не возможно!!! По работе не получается...