Bankir.Ru
3 декабря, суббота 14:39

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

Ваше мнение о кворуме на Btrieve

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Ваше мнение о кворуме на Btrieve

    Уважаемые коллеги!
    пришел работать в банк, где используется АБС Кворум на Btrieve.
    на мой взгляд каменный век ........., но хочется иметь полное и объективное мнение. Помогите составить "портрет" системы и компании производителя.

  • #2
    Для начала (в духе правил форума) я бы все-таки рекомендовал прочитать, хотя бы по диагонали, все сообщения в данном подфоруме (их не так много). И тогда, возможно, "портрет" системы и компании производителя вопросов бы не вызывал.

    Что касается допотопности Btrieve - этот вопрос также многократно обсуждался и не только в данном подфоруме, но и в контексте других АБС. Ищите, и обрящите.
    Для небольшого банка Кворум на Бтриве обеспечивает вполне сносные характеристики - БД технически вполне надежна, нетребовательна к железу, почти не требует администрирования, дешева.
    Есть две проблемы. Первая - масшатбирование. Начиная с некоего порога объема БД и количества ежедневных транзакций Бтривовская технология начинает создавать проблемы. Вторая - хотя Кворум и поддерживает Бтривовскую версию, но основная часть нововведений попадает в версию на Оракле раньше, а некоторые и вообще не доходят до Бтрива - производитель сосредотачивает основные усилия на объективно более совеременной и востребованной версии продукта.
    Так что хорош или не хорош Кворум на Бтриве - зависит от решаемых задач и перспектив развития банка.

    Комментарий


    • #3
      heg
      Подскажи пожалуйста, после смены Btrieve c 6.15 на 7.82 (Pervasive SQL200 SP2) при восстановлении таблиц из atbase размер таблицы увеличивается на 30%.. В bti.cfg настроен на создание таблиц в формате 6.*..
      Как это можно об"яснить ?

      Комментарий


      • #4
        Как это можно об"яснить ?
        Честно ? Не знаю.
        Я же не знаю, какой именно алгоритм восстановления таблиц заложен в atbase.
        Кстати переходить с Бтрива 6.15 на Первэйсив 7/2000 нам не довелось. С самого начала использования нами Кворума (с 1999) мы уже работали на Первэйсиве 7. Правда таблицы для совместимости делали еще формата 6.х. Потом на формат таблиц 7.х мы переходили как-то уж очень плавно и размазано. Сначала в настройках Первэйсива параметр "Create file version" выставили в 7.х, потом сервер поменяли с Pervasive 7 на SQL2000, а потом несколько раз с версии на версию переходили со всеми процедурами восстановления таблиц и т.д. И все это было прозрачно, ничего вроде бы особо не падало, я как-то ни разу не догадался сравнить размер БД до и после.

        А вот, еще кстати, установка сервис-паков Первэйсива заметно влияла на стабильность в лучшую сторону. Особенно заметили, когда поставили SP5 на клиентов Perv SQL7 - значительно снизилось количество ран-тайм-ерроров в АРМах Кворума. А SP4 для сервера Perv SQL2000 похоже улучшил работу транзакций - резко снизилась частота возникновения взаимоблокировок.

        Комментарий


        • #5
          Как это можно об"яснить ?
          А SP4 для сервера Perv SQL2000 похоже улучшил работу транзакций - резко снизилась частота возникновения взаимоблокировок.
          Странно.... мне всегда казалось, что взаимоблокировки зависят от порядка блокировки таблиц в логике, а не от сервера. Может Кворум модернизировал логику ?

          Комментарий


          • #6
            arc
            мне всегда казалось, что взаимоблокировки зависят от порядка блокировки таблиц в логике, а не от сервера

            Извиняюсь, я сказал SP4, на самом деле соответствующее улучшение было еще в SP3 (просто мы их ставили в один день, вот я и перепутал).
            Вот цитата из Whatsnew к SP3 по этому поводу:
            Row Level Locking...
            ...Prior to this release, the database engine locked an entire page containing more than one record in order to update any record on that page. Any other client attempting to update records on that page while the page was still locked had to wait until the first operation released the page lock. This behavior occurred even though the records needed by the second operation were not affected by the first operation.
            With the new row level locking architecture, a transaction locks only the records that it affects directly, not the entire page. One client can update records on a given page at the same time as another client updates different records on the same page...
            Из этого текста ИМХО следует, что после SP3 вероятность попасть в ситуацию взаимоблокировки стала существенно ниже, чем до SP3.
            Т.е., я согласен с Вами, что сами взаимоблокировки зависят от логики прикладной программы, но особенности реализации сревера до SP3 ситуацию усугубляли - повышали вероятность срабатывания потенциально возможной ошибки.
            Последний раз редактировалось heg; 11.02.2004, 13:14.

            Комментарий


            • #7
              heg
              То что вы описали - это не взаимоблокировки, это очередь клиентов. Пока первый не закончит транзакцию, второй будет ждать. Я понимаю взаимоблокировки как deadlock, а это уже бизнес логика.
              Я помню когда мы перешли на PSQL 7.0 то стало хоть видно, кто держит всю очередь и если его убить (если необходимо ) то очередь двинется, но в основном это были проблемы с кворумовской логикой. А row lock в отличие от page lock - это конечно серьезный шаг вперед.

              Комментарий


              • #8
                Да все правильно, я же и не спорю
                Просто хотел сказать, что при блокировке целых страниц вероятность того, что не совсем корректно написанная бизнес-логика вызовет deadlock больше, чем при блокировке отдельных записей - потенциально опасные места большего размера, что ли.
                Например (пример условный, не придираться !!!), если система из-за ошибки в логике, останавливалась, когда два клиента претендовали одновременно на запись N в одной из таблиц, то в случае страничной блокировки тоже самое происходило, когда два клиента претендовали на любую из записей блока N, N+1, N+2... N+x. Причем возможно на _разные_ записи внутри этого блока - тем не менее друг друга блокировали.
                Впрочем, может быть я и не совсем прав, спорить дальше не буду.

                Во всяком случае последовательная установка SP к Первэйсиву стабильность Кворума не ухудшала. А субъективно даже и улучшала. Вполне вероятно (и даже наверняка), что и Кворум свою бизнес-логику постепенно дорабатывал, удаляя узкие места, в этом Вы тоже правы.

                Комментарий


                • #9
                  heg
                  Спасибо большое за ответы.. Кстати, на какой платформе у вас работает Pervasive?

                  Давайте продолжим. Я так понимаю, когда говорят о SP3, 4, то подразумеваются сервис паки к pervasive SQL2000i ? Это все таки отдельный продукт (не SQL2000) то есть нужно ли покупать лицензии на него? Насколько я понимаю, SP3, и SP4 не установятся на SQL2000..

                  И еще, скажите по опыту, какой размер таблицы "считается" для Pervasiva -Кворума большим, то есть где тот порог "большой БД"?

                  Есть предложение обсудить конфигурационный файл Бтрива (2000) на предмет оптимальных настроек.. (в 6.15 их было много меньше) Поскольку мы только переходим на него пока есть время экспериментировать.

                  Комментарий


                  • #10
                    la5
                    Давайте продолжим. Я так понимаю, когда говорят о SP3, 4, то подразумеваются сервис паки к pervasive SQL2000i ? Это все таки отдельный продукт (не SQL2000) то есть нужно ли покупать лицензии на него? Насколько я понимаю, SP3, и SP4 не установятся на SQL2000..

                    Насколько я понимаю, Pervasive.SQL 2000i это и есть бывший SQL 2000, после установки SP3. Просто вместе с этим сервис-паком были внесены достаточно существенные изменения в API, поменялся язык и т.п. Поэтому решено было всю эту конструкцию обозвать новой буковкой.
                    Так что можно ставить SP3 и SP4 поверх вашего Perv.SQL 2000 SP2a - заново закупать лицензии не придется.

                    Остальное - в b-mail

                    Комментарий


                    • #11
                      Сообщение от heg
                      Для начала (в духе правил форума) я бы все-таки рекомендовал прочитать, хотя бы по диагонали, все сообщения в данном подфоруме (их не так много). И тогда, возможно, "портрет" системы и компании производителя вопросов бы не вызывал.

                      Что касается допотопности Btrieve - этот вопрос также многократно обсуждался и не только в данном подфоруме, но и в контексте других АБС. Ищите, и обрящите.
                      Для небольшого банка Кворум на Бтриве обеспечивает вполне сносные характеристики - БД технически вполне надежна, нетребовательна к железу, почти не требует администрирования, дешева.
                      Есть две проблемы. Первая - масшатбирование. Начиная с некоего порога объема БД и количества ежедневных транзакций Бтривовская технология начинает создавать проблемы. Вторая - хотя Кворум и поддерживает Бтривовскую версию, но основная часть нововведений попадает в версию на Оракле раньше, а некоторые и вообще не доходят до Бтрива - производитель сосредотачивает основные усилия на объективно более совеременной и востребованной версии продукта.
                      Так что хорош или не хорош Кворум на Бтриве - зависит от решаемых задач и перспектив развития банка.
                      Подскажите пожалуйста, какой банк по Вашему мнению считается небольшим, в плане использования Бтривовской или Оракловой версии (кол-во счетов, юзеров, транзакций и т.д. на Ваше усмотрение)? Какие характеристики являются критичными?

                      Какова дальнейшая судьба Бтривовского варианта Кворума? (некоторые фирмы-разработчики отказываются от сопровождения своей АБС под Btrieve)?

                      И если это не очень секретная информация, может быть кто-нибудь подскажет, процентное (можно и количество ) соотношение пользователей (в смысле банков), работающих на Бтривовской и Оракловой версии Кворума.
                      Vika

                      Комментарий


                      • #12
                        Подскажите пожалуйста, какой банк по Вашему мнению считается небольшим, в плане использования Бтривовской или Оракловой версии (кол-во счетов, юзеров, транзакций и т.д. на Ваше усмотрение)? Какие характеристики являются критичными?

                        Для начала предлагаю посмотреть, как на этот вопрос отвечают сами разработчики. Вот рекламная страничка с основными свойствами системы:
                        http://www.banking.quorum.ru/index.php?page=37
                        Там есть картинка, с рекомендуемыми диапазонами количества документов и количества пользователей для Бтрива и для Оракла:
                        http://banking.quorum.ru/data/masshtabiruemost-2.gif

                        Мое личное мнение (имхо!), основанное на практике эксплуатации бтривовой версии в нашем банке, практически совпадает с мнением разработчиков. При количестве пользователей менее 40 человек и при количестве документов в день менее 1000, мы практически не сталкивались с какими-либо проблемами Бтрива. А вот, как толко пользователей становится более 50, документов несколько тысяч в день, а еще объем отдельных таблиц в БД начинает существенно превышать 1 ГБ, вот тут все сильнее появляется желание перейти на более современные технологии. А если еще требуется объединять в единую сеть несколько доп.офисов...
                        А еще многое зависит от количества и каечства on-line услуг, которые вы собираетесяь оказывать. С сервером Оракла подобные внешние приложения интегрируются намного проще и качественнее.

                        Комментарий


                        • #13
                          VikaR
                          Мы стали испытывать большие проблемы с Битривом при количестве пользователей более 100.
                          Покупать сейчас битривовский Кворум неразумно, потому что его поддержка вот-вот закончится. Скоро выйдет АБС NEXT и поддерживать 3 АБС никакая фирма не сможет. Понятно, что в первую очередь пожертвуют Битривом, т.к. его поддержка самая трудоемкая, потом Кворумом на Оракл (но позже ). Последний гораздо легче в собственной поддержке.
                          Насколько я знаю, сейчас битривовских банков по количеству больше, но как только на Оракл перейдет Абсолют-банк и все филиалы Росбанка, то уже все крупные (по Кворумовским меркам ) банки будут на Оракле и тогда сами понимаете, что будет.

                          Комментарий


                          • #14
                            heg arc
                            Большое спасибо Вам за подробные ответы!

                            С уважением
                            Vika

                            Комментарий


                            • #15
                              Кстати про Кворум & ORACLE:

                              А что, собственного, нового за последние 2-3 года Кворум сделал в ораклевой версии ?
                              По нашему мнению ничего.
                              Более того, можно сказать, что процесс перевода на ORACLE все есче продолжается!
                              (и результаты этого процесса не могут радовать: процедуры с ильюхера на PL\SQL переносяться методом "как оно есть")

                              Возникает вопрос: А есть ли будующее у ораклевой версии или она так и останется на уровне "прошлого века" ?

                              (По слухам клиентская часть до сих пор использует вызовы через OCI интерфейс 7-ой версии ORACLE. А на дворе уже 10G !)

                              Так не пора-ли, господа, задуматься: "А что дальше ?"

                              Комментарий


                              • #16
                                RedPank
                                (По слухам клиентская часть до сих пор использует вызовы через OCI интерфейс 7-ой версии ORACLE. А на дворе уже 10G !)
                                Оракловый клиент меняется очень слабо от версии к версии, в отличие от самого сервера. Вызовы от Оракла 7.3 были в начале нашего перехода на Оракл, но это поправили и сейчас клиент от 7.3 Кворуму не нужен.

                                А есть ли будующее у ораклевой версии или она так и останется на уровне "прошлого века" ?
                                А какое будущее у нее может быть, если сам Кворум "поставил" на Next ? а прежние инкарнации "слегка поддерживает".

                                Комментарий


                                • #17
                                  Создается интересная ситуация, когда будущего у существующих систем нет, а новой системы есче нет...

                                  Возникает вопрос: стоит-ли переходить с Btrive на Oracle или стоит подождать появления NEXT (вопрос в том - сколько ждать).
                                  Боюсь, что при появлении NEXT на Btrive-версию сразу "положат", а Oracle-версия окажется в положении в котором сейчас находиться Btrive.

                                  P.S.
                                  Переход на NEXT будет равносилен переходу на АБС от другого производителя. Интересно, как Кворум будет "бороться" за "своего" пользователя.

                                  Фирма Кворум и Московский кредитный банк объявили о пилотном проекте по внедрению в МКБ интеграционной платформы NEXT.

                                  arc Как впечатления ?

                                  Комментарий

                                  Пользователи, просматривающие эту тему

                                  Свернуть

                                  Присутствует 1. Участников: 0, гостей: 1.

                                  Обработка...
                                  X