Элтекс

НЦС не запускается с версией FB 2.5
По трейсам сервера видно следующее:

Statement 36:
-------------------------------------------------------------------------------
SELECT CAST('NOW' AS TIMESTAMP) from RDB$DATABASE

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$DATABASE NATURAL)

2012-12-10T11:08:49.9630 (1436:01E8C65C) ERROR AT jrd8_start_transaction
D:\111\MC240-NET.FDB (ATT_32, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\111\NCS\NCS.exe:4604
335544330 : invalid parameter in transaction parameter block
335544889 : Option isc_tpb_rec_version requires READ COMMITTED isolation in TPB

Можно откомпилить НЦС, добавив в TpFIBTransaction.TRParams параметр read_commited или указав TpFIBTransaction.TPBMode:=tpbReadCommitted ?
И наверное было бы желательно обновить версию FIBPlus, если Вас не затруднит.

И еще просьба по FBLoader:
При распарсивании каждого файла программа выполняет запрос SELECT COUNT(*) FROM converslog
Записи из Converslog периодически переносятся в Conversarch, но тем не менее, этот запрос выполняется около 30-40 секунд, что существенно тормозит суммарное время загрузки с около 150 станций. Я не пойму для чего нужен этот запрос? Можно его убрать?

Программы предназначенные на использование сервера FB1.5 никак не будут работать с версиями FB 2.0 и 2.5.
Необходимо устанавливать последнюю версию линейки FB1.5

FBLoader с Firebird 2.5.2 работает нормально. В NCS необходимо только добавить вышеуказанный параметр подключения.
Собственно, из-за чего начались пляски: подключили к мониторингу одну сельскую АТС, там накопился файл с билингом около 20 МБ. Загрузка/распарсивание этого файла затянулась на сутки. Окончания я не дождался и решил попробовать перейти на FB 2.5.2, т.к. обещали улучшение параллелизма и производительности. Плюс наличие трейсов.

По трейсам удалось выяснить, что по каждой (вроде как) записи FBLoader осуществляет SELECT-запрос к таблице LONG_CALLS в которой индекс только по первичному ключу, а за всё время таблица неплохо разрослась...

Ну и на 2.5.2 действительно лучше распараллеливается. В 1.5 грузится только одно ядро, не смотря на параметр CpuAffinityMask в firebird.conf

Поднимать отдельно сервер FB для NCS и для базы с биллингом как-то не рационально. Поэтому хотелось бы получить потдержку NCS-ом версии 2.5.2, к тому же, многого для этого не требуется.

Select count(*) from converslog - собственно проверка не пора ли перекинуть в архив. Немного неожиданно что парсится 150 файлов подряд, потому и не учли что это не оптимально в таком случае.
Запланируем переделку.

По таблице LONG_CALL. Теоретически она не должна накапливать записи, так как это информация о кусках длинных разговоров, которые после окончания склейки полностью удаляются из таблицы.
Источником накопления может быть:
- потери концовок, т.е. конец разговора так и не был обработан, потому остались его неполные части.
- неправильный порядок разбора и/или двойной парсинг файлов. При парсинге порядок имеет значение: файлы должны подаваться на вход в том же порядке как они писались станцией. Т.е. чтобы разговор, попавший в разные файлы, накапливал свои куски в правильном порядке.

Для адекватной помощи не могли бы Вы посмотреть за какой период накопились данные в таблице LONG_CALL и их общее количество? и как оно коррелирует с количеством всех обработанных записей биллинга?
Если там есть довольно старые записи можно будет их удалить SQL запросом. Полагаю у вас на АТС нет разговоров длящихся месяцами?

По поводу FB2.5 - необходимы исследования с нашей стороны, без них ничего сказать не можем. Возможно появилась некоторая совместимость в новых версиях FB, но с этим надо разбираться.
Попробуем выделить на это время, но заранее ничего не обещаем.

Алексей Сергеев писал(а):По таблице LONG_CALL. Теоретически она не должна накапливать записи, так как это информация о кусках длинных разговоров, которые после окончания склейки полностью удаляются из таблицы.
Источником накопления может быть:
- потери концовок, т.е. конец разговора так и не был обработан, потому остались его неполные части.
- неправильный порядок разбора и/или двойной парсинг файлов. При парсинге порядок имеет значение: файлы должны подаваться на вход в том же порядке как они писались станцией. Т.е. чтобы разговор, попавший в разные файлы, накапливал свои куски в правильном порядке.

Для адекватной помощи не могли бы Вы посмотреть за какой период накопились данные в таблице LONG_CALL и их общее количество? и как оно коррелирует с количеством всех обработанных записей биллинга?
Если там есть довольно старые записи можно будет их удалить SQL запросом. Полагаю у вас на АТС нет разговоров длящихся месяцами?

- Потери концовок по идее быть не должно, данные снимаются через BillReader, у станционных инженеров версия админа без биллинга.
- Последовательность тоже не нарушается. Сняли биллинг со станции - загрузили в базу.
Данные в таблице были с начала перехода на FBLoader с поддержкой склейки длинных разговоров. Таблица была подчищена и добавлен индекс. Оставил записи за последние полгода. Сейчас там 258 тысяч записей, в основном соединения pcm-gate'ов, но встречаются и обычные звонки.
В Converslog данные тоже хранятся за полгода, более старые переносятся в Conversarch. Сейчас там ~16.4 миллиона записей.

Да. Про pcm-gate я как-то не подумал. Там действительно звонки длятся бесконечно, и как правило финала нет, так как по рестарту АТС звонок не успевает финализироваться. Надеюсь pcm-gate не тарифицируются?
Попробуем подобрать оптимальные параметры для удаления несущественных данных из базы LONG_CALL.
Помниться я делал режим в bin2dbf в котором скидывались только незавершенные разговоры из базы. Добавить туда же функцию по очистке.
Т.е. выдать список незаконченных разговоров, скажем старее пары суток от последнего импорта, чтобы убедиться что разговор больше не продолжается, подсчитать их накопленную длительность, и удалить из базы, так как финала разговорам уже не будет.
Вас заинтересует такая функция?

Алексей Сергеев писал(а):Надеюсь pcm-gate не тарифицируются?

С гейтов соединения на тарификацию не подаются.

Алексей Сергеев писал(а):Вас заинтересует такая функция?

Да, было бы логично склеивать и соединения без финальной части, а то сейчас получается такие звонки как бы вообще "теряются", не попадая в Converslog даже с неполной длительностью.

Алексей Сергеев писал(а):По поводу FB2.5 - необходимы исследования с нашей стороны, без них ничего сказать не можем. Возможно появилась некоторая совместимость в новых версиях FB, но с этим надо разбираться.
Попробуем выделить на это время, но заранее ничего не обещаем.

Под совместимостью Вы имеете в виду сам NCS или базу данных формата 1.5 с сервером 2.5? База данных конвертируется в формат FB 2.5 через backup/restore. NCS, на сколько я понял, подключается к базе через библиотеку компонентов FIBPlus, она FB2.5.2 поддреживает.