Связка ИБСО - Банк клиент BSS
На страницу Пред. 1, 2, 3 След.
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
OlegFB
Участник - экстремал
Вступление в Клуб: 11.07.2007
|
 Ср Дек 19, 2007 19:49 |
 |
Полезность: Нет оценки
|
Мы используем Квадриумовскую связку... есть и плюсы и минусы...
В данный момент наблюдаю процесс внедрения родной ЦФТ-шной связки...
первой большой проблемой было совместить версии шлюзов (комплекты процедур) от BSS и от ЦФТ - ибо с каждой стороны имеется по нескольку вариантов, и найти удовлетворительно работающую связку удалось после 2-х недель экспериментов...
Причем работающую условно - пришлось достаточно много дорабатывать напильником... (чаще со стороны ИБСО)
Полностью согласен с faded по поводу обязательного наличия "вспомогательных/транспортных структур для хранения запросов внешней системы"... в ЦФТ-шном варианте этого практически нет...
У квадриума есть что-то подобное, но далекое от совершенства...
Вообще (надеюсь, не раскрою комерческой тайны) у квадриума реализованы два основных ТБП:
1. Собственно продукт, в котором ведётся администрирование армов-договоров-счетов.
2. документы эл. клиентов (та самая транспортная структура)... |
|
 |
OlegFB
Участник - экстремал
Вступление в Клуб: 11.07.2007
|
| Ср Дек 19, 2007 19:55 |
|
Полезность: Нет оценки
|
| ГлСП пишет: |
В свое время видел один такой мост. Работал напрямую с таблицами БСС через DBLink. Но там, имхо, одно условие, чтобы сам БСС был на оракле.
|
Оба варианта описанные мной в предыдущем посте работают через DBLink, причем в одном из них BSS крутится на MS SQL ест-но под виндой...
Насколько я понял, главное что бы СУБД, на которой крутиться BSS, поддерживала ODBC (кажется его, ежели не путаю). |
|
|
pychick
Участник
Вступление в Клуб: 28.01.2009
|
| Пт Апр 03, 2009 08:47 Поднимая сабж |
|
Полезность: Нет оценки
|
Доброе утро, коллеги. А ни у кого, случаем, нет ли опыта связки БСС и РБО через Z$CIT_BO_EXT_CALL_LIB?
_________________
семь раз отпей, один отъешь |
|
|
kopaygora
Участник
Вступление в Клуб: 24.06.2009
|
| Чт Июн 25, 2009 11:39 |
|
Полезность: Нет оценки
|
Здравствуйте.
Подскажите, пожалуйста, в чем может быть причина постоянной загрузки CPU БД выше 90% + RAM БД >1Gb процессом cbmain.exe, выполняющим запрос:
select * from BS3$Document where (sStatementID=:1) and (sAccount=:2) and (dtDate >= :3) and (dtDate < :4)
В таблице BS3$Document 1 079 448 строк.
Со стороны сервера BSS в настройках связки с АБС:
Макс. глубина выписки =7дн.
Глубина выписки=3дн.
Второй сервер BSS, работающий с этой же БД, имеет такие же настройки значений по выписке, но CPU и RAM практически не потребляет.
Заранее спасибо. |
|
|
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
| Пн Июн 29, 2009 17:03 |
|
Полезность: Нет оценки
|
| kopaygora пишет: | Здравствуйте.
Подскажите, пожалуйста, в чем может быть причина постоянной загрузки CPU БД выше 90% + RAM БД >1Gb процессом cbmain.exe, выполняющим запрос:
select * from BS3$Document where (sStatementID=:1) and (sAccount=:2) and (dtDate >= :3) and (dtDate < :4)
В таблице BS3$Document 1 079 448 строк.
Со стороны сервера BSS в настройках связки с АБС:
Макс. глубина выписки =7дн.
Глубина выписки=3дн.
Второй сервер BSS, работающий с этой же БД, имеет такие же настройки значений по выписке, но CPU и RAM практически не потребляет.
Заранее спасибо. |
Висит постоянно один и тот же сервер. Либо висит всегда тот котороый стартанул последним?
Включите трассировку сесии от повисшего сервера, может там будет наглядее видно почему запрос висит... |
|
|
ГлСП
Профи
Вступление в Клуб: 20.09.2007
|
| Пт Сен 25, 2009 11:38 |
|
Полезность: 1
|
| kopaygora пишет: | Здравствуйте.
Подскажите, пожалуйста, в чем может быть причина постоянной загрузки CPU БД выше 90% + RAM БД >1Gb процессом cbmain.exe, выполняющим запрос:
select * from BS3$Document where (sStatementID=:1) and (sAccount=:2) and (dtDate >= :3) and (dtDate < :4)
В таблице BS3$Document 1 079 448 строк.
Со стороны сервера BSS в настройках связки с АБС:
Макс. глубина выписки =7дн.
Глубина выписки=3дн.
Второй сервер BSS, работающий с этой же БД, имеет такие же настройки значений по выписке, но CPU и RAM практически не потребляет.
Заранее спасибо. |
В этой таблице вообще ничего не должно быть. Изначально она была темповой, но потом темповость убрали, не помню почему, заменили на ид сессии. После того, как бсс отрабатывал загрузку, он должен был за собой подчищать, т.е. удалять все документы из таблицы документов. По началу это так работало, но после очередного патча перестатало работать. Когда мы это обнаружили, то сделали снова BS3$Document и BS3$Records темповывыми по окончанию сессии. |
|
|
arsa81
Участник
Вступление в Клуб: 23.10.2008
|
| Чт Дек 17, 2009 11:25 |
|
Полезность: Нет оценки
|
| kopaygora пишет: | Здравствуйте.
Подскажите, пожалуйста, в чем может быть причина постоянной загрузки CPU БД выше 90% + RAM БД >1Gb процессом cbmain.exe, выполняющим запрос:
select * from BS3$Document where (sStatementID=:1) and (sAccount=:2) and (dtDate >= :3) and (dtDate < :4)
|
А если план выполнения запроса глянуть? Случайно не FULLSCAN? |
|
|
ГлСП
Профи
Вступление в Клуб: 20.09.2007
|
| Пн Дек 28, 2009 14:25 |
|
Полезность: Нет оценки
|
| arsa81 пишет: | | kopaygora пишет: | Здравствуйте.
Подскажите, пожалуйста, в чем может быть причина постоянной загрузки CPU БД выше 90% + RAM БД >1Gb процессом cbmain.exe, выполняющим запрос:
select * from BS3$Document where (sStatementID=:1) and (sAccount=:2) and (dtDate >= :3) and (dtDate < :4)
|
А если план выполнения запроса глянуть? Случайно не FULLSCAN? |
Там в принципе не должно быть фулла, т.к. , если правильно накатить скрипт при созданию этих таблиц, то индексы должны сформироваться.
А вот то, что записи накапливаются в темповых таблицах, то это мы проходили.
Хотя может и другая версия там стоит. Хотя не думаю, что БСС будет точить шлюз под каждую подверсию этого шлюза. |
|
|
arsa81
Участник
Вступление в Клуб: 23.10.2008
|
| Пн Дек 28, 2009 17:26 |
|
Полезность: Нет оценки
|
| Это конечно банально, но фулл может возникнуть из-за переконвертации типов. Например индекс построен по float, а передается скажем binary_double. |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Чт Апр 08, 2010 15:03 |
|
Полезность: Нет оценки
|
| ГлСП пишет: | | В этой таблице (BS3$Document) вообще ничего не должно быть. Изначально она была темповой, но потом темповость убрали, не помню почему, заменили на ид сессии. После того, как бсс отрабатывал загрузку, он должен был за собой подчищать, т.е. удалять все документы из таблицы документов. По началу это так работало, но после очередного патча перестатало работать. Когда мы это обнаружили, то сделали снова BS3$Document и BS3$Records темповывыми по окончанию сессии. |
Сергей! А BS3$Result у Вас сейчас тоже темповая? По окончании сессии?
У нас почему-то с темповой не работает получение выписки (документы, на удивление нормально), а именно добавление счета. Как только сделал таблицу не временной - все заработало.  Согласно логам сессия одна и та же. |
|
|
ГлСП
Профи
Вступление в Клуб: 20.09.2007
|
| Пт Апр 09, 2010 08:54 |
|
Полезность: 1
|
| timochev пишет: |
Сергей! А BS3$Result у Вас сейчас тоже темповая? По окончании сессии?
У нас почему-то с темповой не работает получение выписки (документы, на удивление нормально), а именно добавление счета. Как только сделал таблицу не временной - все заработало. Согласно логам сессия одна и та же. |
Нет, Result у нас обычная таблица
| Код: |
create table BS3$RESULT
(
REFER NUMBER,
CODE NUMBER,
NAME VARCHAR2(4000),
DTDATE DATE,
SSTATEMENTID VARCHAR2(50),
DSTATEMENTDATE DATE default sysdate
)
create index BS3$RESULT$SSTID on BS3$RESULT (SSTATEMENTID)
|
А вот records у нас темповая
| Код: |
-- Create table
create global temporary table BS3$RECORDS
(
SACCOUNT VARCHAR2(34),
SACCCURRENCY VARCHAR2(3),
DTDATE DATE,
NRESTIN NUMBER(24,3),
NRESTOUT NUMBER(24,3),
NRESTOUTPLAN NUMBER(24,3),
SSTATEMENTID VARCHAR2(3 ,
DSTATEMENTDATE DATE default sysdate
)
on commit preserve rows;
|
А вот таблица счетов очищается после коммитта
| Код: |
-- Create table
create global temporary table BS3$CLIENT_ACC
(
SBSSID INTEGER,
SACCOUNT VARCHAR2(34),
SACCCURRENCY VARCHAR2(3),
SACCNAME VARCHAR2(100),
SACCTYPE VARCHAR2(30)
)
on commit delete rows;
|
Но в процедуре добавления счетов убрал все коммиты, как и у нас , так и в скриптах BSS. |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Пт Апр 09, 2010 09:03 |
|
Полезность: Нет оценки
|
Сергей, огромное спасибо!
А таблица счетов у вас как используется? Для передачи списка для выписки? У нас pl/sql таблица для этого заполняется.
Оказалось, что в части работы с выпиской c BS3$RESULT в новой версии шлюза работают 2(!) сессии. Это показала оракловая трассировка. |
|
|
ГлСП
Профи
Вступление в Клуб: 20.09.2007
|
| Пт Апр 09, 2010 09:06 |
|
Полезность: Нет оценки
|
Дима, у нас обновление было последний раз 23 февраля. Я загрузил наших БССников.
Сейчас у нас работает две сессии. чем они занимаются, я не знаю, но мы изначально ограничили их количество.
Что могу порекомендовать
Снять темповость с таблицы счетов, и если БСС не будет подчищать за собой, то, или наехать на БСС, по причине того, что они не подчищают за собой, или хранить все SSTATEMENTID где-то у себя, и потом джобом вычищать раз в сутки по нему. |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Пт Апр 09, 2010 09:11 |
|
Полезность: Нет оценки
|
| ГлСП пишет: | Дима, у нас обновление было последний раз 23 февраля. Я загрузил наших БССников.
Сейчас у нас работает две сессии. чем они занимаются, я не знаю, но мы изначально ограничили их количество.
|
У нас сейчас сессии размножаются в количестве до 5 штук.
Плохо, что непонятно, чем они все занимаются. И как распределяется между ними работа... |
|
|
ГлСП
Профи
Вступление в Клуб: 20.09.2007
|
| Пт Апр 09, 2010 10:45 |
|
Полезность: Нет оценки
|
| Там вроде как можно поставить ограничение на количество сессий. Попробуйте 2 сессии поставить |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
