kdv,

kdv Другое дело, что при -shut force 0 существующие коннекты не убиваются, а в них просто "прекращаются любые операции". Это для вас проблема?
Да, к сожалению это и является проблемой. Сейчас команды shutdown/online выполняются через компонент IBConfigService я так понимаю через Service API, выполняется команда


еще такой вопрос: откуда информация о kdvлюбое (первое) обращение в транзакции к любой таблице mon заставляет сервер опрашивать все процессы классика для формирования содержимого всех таблиц mon$. На серверах с большим количеством пользователей и высокой нагрузкой это может занимать до 5 минут. Если вы будете "мониторить" сервер через mon$ каждые 5-10 минут, то это значит, что вы его фактически "затрахиваете". потому что на деле оно так не получается. У нас самый большой клиент имеет 120-130 коннектов, каждые 5 минут мы опрашиваем таблицы mon$ и по времени доставки нам результатов не видно просаживания производительности, стабильно каждые ~5-6 минут приходит результат (погрешность времени из-за отправки письма нам на корпоративную почту). И это при том, что жесткие диски сервера клиентов имеют маленькие скорости чтения-записи ~30 Мб/с, что для их железа в 3-4 раза меньше заявленного.

Симонов Денис,

Симонов ДенисКстати что имеется ввиду под "сервер клиентов"?

имеется в виду серверная машина клиентов.

kdv,

gstat -h:

Database "C:\database\mainbase.fdb"
Database header page information:
Flags 0
Checksum 12345
Generation 205356
Page size 16384
ODS version 11.2
Oldest transaction 161531
Oldest active 191351
Oldest snapshot 191351
Next transaction 191364
Bumped transaction 1
Sequence number 0
Next attachment ID 13750
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date May 20, 2014 12:35:23
Attributes force write, multi-user maintenance

Variable header data:
Sweep interval: 0
*END*

порядок действий: я подключился удаленно к БД через IBExpert на нашем локальном корпоративном сервере, на нем стоит FB clasic 2.5.2.26540. Запустил IBExpert на сервере и выполнил в нем команду Shutsown database. IBExpert на моей машине выдал милое сообщение, что соединение было прервано. Повторная попытка подключения меня мягко говоря послала (прикрепляю скрин)

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

Freddie26,

kdv,

IBExpert на корпоративном сервере старенький, правда сейчас не могу сказать на сколько он стар. На моей машине стоит максимум месячной давности сборка. В том то и проблема, что бардака быть не должно. Разве FB не должен работать что называется "из коробки" - устанавливается все практически по дефолту выбирается разве что версия сервера СУБД? никаких дополнительных настроек не производилось. Конкретный пример: два IBExpert-а оба подключаются под SYSDBA, первый - удаленно, второй - локально. Второй отдает команду Shutdown. Оба коннекта закрываются. Первый говорит БД в Shutdown, второй говорит "ошибка". О каких настройках речь? Я могу видео записать если это как-то поможет решить проблему. Если речь идет о баге, думаю о нем стоит сообщить разработчикам, но мне казалось, что о нем известно. Сотрудник, как я понял с его слов, находил информацию, что люди на других форумах жаловались на подобное поведение FB и конкретно на Clasic server если я ничего не путаю (у него исполняемый файл fb_inet_server.exe). В то время как на других версиях СУБД (Superclasic и Superserver) такой проблемы не наблюдается.

Dimitry Sibiryakov,

IBExpert и компоненты IBX/FireDAC - левые средства?! Прошу прощения, а зачем тогда это все разрабатывается, если им не пользоваться? Может стандартные утилиты и лучше, но половина вообще нигде не описана, вторую половину программно запускать можно, но контролировать процесс практически не возможно. Никогда не знаешь что ты получишь в итоге. В то время как API нацелены на то, что разработчик получит желаемый результат или будет знать в чем именно ошибка. Да я могу в частном случае делать Backup/Restore при помощи gbak, но когда у меня 100 серверов и не везде есть админы, а там где есть и то толку мало и каждое утро приходишь и выслушиваешь что у какого то клиента какие-то проблемы в очередной раз всплыли, винят во всем СУБД, разработчиков, да что угодно кроме того, что у них ОС-ь криво стоит, драйверы левые, бесперебойника нет и железо сбоит, вооще не поддерживаемая ОС-ь... Мы отказались от стандартных утилит потому что приложению не хватает прав на некоторых машинах для запуска этих утилит из командной строки. Клиенты понаставят различного уровня защиту (от UAC в ОС Windows до антивирусов различной паршивости и различных прокси) и приходится ваять всё новые и новые костыли, чтобы это как-то работало и они - те кто без админов, но слишком умные и лезут вмешиваться в работу приложения никак не могли помешать работе программы или программа в конечном итоге отработала... Еще полгода назад я о Firebird даже не слышал, теперь прочитал не одну вашу статью по СУБД, различные статью с других форумов и сайтов где хоть как то описываются интересующие проблемы, и более того приходится делать различного уровня "защиту от дурака", потому что чуть пытаешься делать какое-то обслуживание, так пользователи тут же суют туда нос, ребутят приложение, машину. А потом еще и спрашивают почему все не работает.

Простите конечно, но стандартными утилитами уже не получается пользоваться. Накипело.

kdv,

Прошу прощения, не видел этого сообщения, иначе бы ответил.

kdvFreddie26Оба коннекта закрываются. Первый говорит БД в Shutdown, второй говорит "ошибка".
при каком действии "второй говорит", и какую ошибку пишет?


Версия IBExpert на корпоративном сервере версия продукта 2007.4.29.1, версия файла 2011.6.29.1, версия FB 2.5.2.26540 (Classic server).
На рабочей машине FB версии 2.5.2.26540 (Super server), к сожалению версию IBExpert рабочей машины сказать в данный момент не могу, на сайте с которого скачивал - сайт , последняя - 2014.03.16 - скорее всего моя

Порядок действий как я и описывал:
1) с рабочей машины IBExpert-ом подключаюсь к БД под пользователем SYSDBA, которая лежит на корпоративном сервере. Не совершаю никаких действий с СУБД. Коннект остается открытым. Скрин с настройками подключения прилагался выше.
2) На корпоративном сервере запускаю IBExpert, подключаюсь к БД под пользователем SYSDBA (пароли, если это имеет значение, не менялись)
3) В главном меню программы выбираю опцию "Базу в даун".
Оба подключения на обоих машинах прекращаются, после чего моя рабочая машина при попытке подключиться под все тем же SYSDBA, все к той же базе и с теми же настройками говорит что БД в Shutdown. IBExpert на сервере при попытке поднять коннект к БД выдает сообщение (скрин).

Я так понимаю коннект рабочей машины "приостановлен" до поднятия БД Online, но коннект под SYSDBA, разве я не должен иметь возможность переподключиться и продолжить работу?

Коннект сервера вообще не поддается моему объяснению. Он завершился, он ничего не делал, не выполнял никаких операций, он сам же отправил БД в Shutdown и в то же время он же не хочет поднимать ее Online и не может подключиться к ней. Опять же настройки не менялись. Нужна какая-то еще информация?

kdv,

статистику я снял сразу же после опыта при помощи gstat -h. Да там режим multi-user shutdown. Честно говоря больше поднимать коннекты не пытался с других машин, если это необходимо могу повторить опыт между несколькими виртуальными машинами удаленно, но не вижу в этом большого смысла, на клиентских серверах у кого такая проблема воспроизводилась (а воспроизводилась она у 15-20 клиентов периодически, повторюсь не у всех стоит classic server).
Честно говоря не уверен что IBExpert настолько старый, компании всего 3 года. больше похоже что он все же 2011-го года.

Симонов Денис,

мой более новый IBE тоже ругается, если выполнять запрос с русскоязычным именем ПК.

Dimitry Sibiryakov,

чарсеты у меня при подключении win1251. Остальные по умолчанию