Если выполнить стандартный запрос IBExpert-а "Database monitoring -> Attachments" (я немного урезал его под свои нужды), то выдает ошибку: arifmetic exception, numeric overflow, or string truncation. Cannot translitirate character between character sets.
Проблема судя по всему заключается в русскоязычном имени ПК, которое должно отображаться в поле "Remote Address". Можно ли как-то преобразовать выводимые данные в рабочий формат да и вообще какой набор символов нужно подсовывать?

Запрос:

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

У меня лично стоит FB 2.5.2.26540 и наблюдается такая же проблема, у клиентов (их примерно 16 с русскоязычным именем ПК) версии FB 2.5, но сборки могут отличаться. Помогает переименование ПК в англоязычное имя, но слетают лицензии на ПО, поэтому я сомневаюсь, что это выход из сложившейся ситуации.

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

Кодировка win1251, TA не используется. В mon$remote_address отображается имя ПК, если подключиться через IBExpert. Проблема в том, что пытаюсь мониторить через приложение подключения к БД и в списке подключенных может быть IBExpert, mon$remote_address которого имеет имя ПК...
Лично на моей машине все пути англоязычные, соответственно остальные поля не должны вызывать ошибку при запросе.
Попробую обновиться до 2.5.3, посмотрим что из этого получится.

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

и еще вопрос пока не забыл. Если делать, например, бэкап, то в этом же "мониторе" отображается подключение к БД, но не отображается mon$remote_process (это поле имеет значение NULL). Вы случайно не в курсе будет ли писаться, что процесс породил gbak, например? Планируются ли подобные изменения?

NickDee,

только что попробовал на клиентской машине в IBExpert открыть монитор под UTF8, ничего не изменилось. Я и приводить поле к UTF8 через cast пробовал - все равно ошибка.

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

На самом деле бэкап вызывается через компонент ADIBBackup в Delphi. Строчка выглядит примерно так:
gbak -b -g *.fdb *.fbk -user SYSDBA -pass masterke (т.е. бэкап без сборки мусора).
Точно так же, если делать бэкап через IBExpert, то в "мониторе" тоже не отображается mon$remote_process.

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

проблема как раз таки есть. Раньше наше приложение сидело под рутовым пользователем, примерно полгода назад мы от этого отказались и создали дополнительную роль для пользователей программы. Сейчас имеем несколько приложений, которые теоретически могут подключаться к БД под рутом. В основном мы используем clasic server. На нем есть такая особеность: если подключиться к БД под рутом и после коннекта отправить БД в shutdown, то потом БД нельзя ни поднять Online, ни снова отправить в shutdown. БД "зависает между состояниями". Чтобы предотвратить эти зависания мы разработали сервис, который мониторит коннекты на серверах пользователей и если кто-то сидит под рутом, то мы меняем настройки на выделенную роль. По мимо коннектов пользователей так же под мониторинг попадает и IBExpert, который коннектится к БД под рутом и как правило стоит для поддержки клиентов (т.е. для разработчиков), но клиенту ничего не мешает им пользоваться.
Проблема еще в том, что некоторые пользователи ("очень умные") пишут сами приложения или где-то их приобретают я не знаю, но как выяснилось через какие-то сторонние приложения коннектятся к нашим БД. Именно поэтому хотелось бы наверняка знать чей коннект поднят.

kdv ,

символы * в имени БД и бэкапа я намеренно поставил, имена у нас задаются корректно, с этим проблем нет.

kdv,

под рутом я имею в виду SYSDBA

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

как раз мониторинг и предназначен чтобы отловить тех, кто использует SYSDBA для подключения к БД. Для 100 клиентов это не просто сделать - взять и сменить логин/пароль на админа, к тому же кучу приложений переписать в множестве мест, где поднимаются коннекты к БД... Мне честно говоря не понятно как мониторинг вообще может влиять на производительность? Это такой же запрос к БД как и остальные, разве что он опрашивает системные таблицы, которые и так нельзя изменить.

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. Остальные по умолчанию

Dimitry Sibiryakov,

Поставил набор символов NONE, запрос выполнился. Спасибо!