16 ноября, пятница 16:38
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Diasoft 5NT, Sybase делимся опытом?

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

  • Diasoft 5NT, Sybase делимся опытом?

    Господа,

    Многие ли из вас пользуют Diasoft 5NT и Sybase? Sybase желательно НЕ на MS платформах.

  • #2
    Mongos Боюсь, что сейчас немного таких банков найдётся... Хотя, очень хотелось бы, чтобы хоть кто-то откликнулся...
    Да пребудет с Тобою Великая Сила! ©

    Комментарий


    • #3
      Mongos
      Судя по последним внедрениям почти все (это правда если верить Диасофту) идут в связке с Sybase. Но реально пощапать мне не удалось. У нас к сожалению (или к радости) все крутится на MSSQL 2K...

      Комментарий


      • #4
        Mongos
        Мы используем, а в чем проблема?

        Комментарий


        • #5
          loo
          Mongos-а как я понимаю интересовало именно сравнение работы системы под MS и под Sybase... Только тут врядли кто ему поможет, все тесты диасофта не несут реальной картины. А кто-то на стороне врядли захочет тестировать систему на двух платформах.

          Комментарий


          • #6
            на самом деле меня больше интересует tuning Sybase под Diasoft 5NT.
            могу поделиться своими мыслями и .т.д. если это кому интересно то надо начать огромный флэйм.

            Комментарий


            • #7
              Mongos
              надо начать огромный флэйм.
              Начинай!
              Лично мое мнение, что нужно почаще тюнговать диасофтовских разработчиков и тестеров.
              Попытки иным путем существенно повлиять на работу этой вещи особых результатов не дали.
              Но... Век живи - век учись.

              Комментарий


              • #8
                А каким опытом надо делиться?

                Знаю что штатные запросы частенько корявые, особенно много их в группе "Формулы", потому как писались, побыстрому и кое-как. Поэтому и скорость работы процедуры и генерации проводки различается в разы.

                А SY знаю очень не любит умничать когда оптимизирует запрос, составляет план и выбирает индекс, Хинт руками - однозначно рулез.
                С уважением, Максаев Андрей.

                Комментарий


                • #9
                  andrey_seek
                  Хинт руками - однозначно рулез
                  причем не только в Sybase... На простых запросах MS еще куда не шло справляется, но как только дело доходит до tOperPart (размером в несколько Гб) все рушится в полный сканинг таблиц

                  Комментарий


                  • #10
                    у кого-нибудь уже работает Sybase 12.5? или "специалисты" из Diasoft'а не дают на него никаких гарантий?

                    Комментарий


                    • #11
                      Mongos
                      Чего, на Java процедуры программировать охота? Али XML беспокоит?
                      И где обещанный флейм про тюнинг-шмунинг? Всякие там named cash-и и прочая?

                      Комментарий


                      • #12
                        loo:
                        чего хочется: raw devices, 8k pages, >2gb memory support, etc, etc, etc...

                        а флэйм зависит не только от меня. может кто-нибудь выскажет свои предположения по поводу тюнинга-шмунинга?

                        Комментарий


                        • #13
                          Mongos
                          Да нет - это все написано в книжке про ASE. Что-нибудь специфически диасофтовское. Например, стоит ли создавать named cash-и и под какие таблицы, как бороться с p-таблицами - лог они загаживают, всякие LRU-MRU на разные индексы.

                          Комментарий


                          • #14
                            Mongos
                            Ставили на тестовые сервер. 12.5 . визуально работает гораздо быстрее чем 12.0. (у нас он щас стоит). Но не перешли из за ошибок, ( некоторые отчеты просто трапались при больших объемах данных). Поддержка sybase ничего не сказала, а Диасофтофцы рекомендовали не гемороится и остатся на 12.0 пока они сами все не оттестируют
                            Последний раз редактировалось SerBor; 12.07.2002, 19:43.

                            Комментарий


                            • #15
                              Вообще давно надо всем миром, подписаться под отменой tDepartment-а как такового. Хранит в основном дубли всех справочников.

                              Половина депо отчетов, лезет в скан по DepHash и все, наступает полный абзац, банк просто стоит, пока у запустившего тайм-аут не отвалится...
                              С уважением, Максаев Андрей.

                              Комментарий


                              • #16
                                andrey_seek
                                Объявляется конкурс - есть счет с тремя-четырьмя субконто - ну, например, бумага, портфель, контрпарнер, валюта. Субконто на счет настраиваются индивидуально, всего в системе могет быть штук 16 разных субконт. Как построить базу, чтобы:
                                1. Обеспечить запрос в tOprPart по хорошему индексу
                                2. Заджойнить полученный результат на справочники по индексам.

                                Что касается твоей проблемы - то это глюк конкретных отчетов (скорее всего там 2 like на tDepartment и уродливый Query Plan).
                                В принципе мы побороли такие проблемы - написали процедурку, которая без Like делает update табичке pResList (заполняет там поля типа SecurityID, DepartmentID, PortfolioID). Если хочешь - могу выслать.

                                Комментарий


                                • #17
                                  andrey_seek
                                  Половина депо отчетов, лезет в скан по DepHash и все, наступает полный абзац, банк просто стоит, пока у запустившего тайм-аут не отвалится...
                                  у нас уже давно все отчеты переписаны. на первую отрытую дату берется остаток из trest, а далее по проводкам собираем движение из открытых дней. работает на порядок быстрее чем юзать dephash.
                                  loo
                                  В принципе мы побороли такие проблемы - написали процедурку, которая без Like делает update табичке pResList (заполняет там поля типа SecurityID, DepartmentID, PortfolioID). Если хочешь - могу выслать.
                                  Лучше сюда. Все и посмотрим. Хотя для меня уже вопрос про dephash уходит на второй план, все счета, кроме депозитарных, теперь никакими субконтами не обладают. Есть правда с десяток счетов для фьючерсов, но это капля в море.

                                  Комментарий


                                  • #18
                                    kvit
                                    Во-первых именно описанным образом дествует стандартная процедура PosList_Rest. Зачем сочинять свою? Результаты (насчитанные остатки) она складывает в табличку pResList.

                                    Комментарий


                                    • #19
                                      Гм. Ничего не приаттачилось вторая попытка.

                                      Комментарий


                                      • #20
                                        loo
                                        Во-первых именно описанным образом дествует стандартная процедура PosList_Rest.
                                        Могу ошибатся, но помоему PosList_Rest не возвращает ссылку на tSecurity (DepHash не в счет). Все о чем я говорил имелось в виду остатки по депозитарным счетам (хотя и по другим можно получать таким же способом) сразу же с ссылкой на tsecurity. Нечто похожее есть в sp GetFacialAccount.

                                        Комментарий


                                        • #21
                                          Да самому все можно сделать, но отчеты ведь Диасофтовские, и добрые "э-э-эхи", постоянно сканируют tDepartment, а за ними за всеми все не перепишешь...

                                          Объявляется конкурс - есть счет с тремя-четырьмя субконто - ну, например, бумага, портфель, контрпарнер, валюта. Субконто на счет настраиваются индивидуально, всего в системе могет быть штук 16 разных субконт. Как построить базу, чтобы:
                                          1. Обеспечить запрос в tOprPart по хорошему индексу
                                          2. Заджойнить полученный результат на справочники по индексам.

                                          я думаю что легко, к tOperPart - сделать tOperPart_DepHash
                                          (OperationID, CharType, DepartmentID) - как минимум
                                          или уж (OperationID, CharType, SubcontoType, ObjectID) и заполнение например по триггеру

                                          и места я уверен будет занимать уж гораздо меньше чем строка DepHash. И индексы будут и все остальное. Нормализации уж лет 50 наверно скоро будет...
                                          С уважением, Максаев Андрей.

                                          Комментарий


                                          • #22
                                            kvit
                                            Гм. Действительно не возвращает. Меня как-то отдельно SecurityID пока не волновали, клиенты и места хранения у нас тоже субконтами. Ну так вам надо было на Диасофт наехать, там пару байт всего добавить.
                                            Кстати, а что, никто не пользуется архивацией проводок?

                                            Комментарий


                                            • #23
                                              andrey_seek
                                              Предложенное решение не удовлеворяет условию 1. Например, чтобы выбрать остатки по одной бумаге придется перебирать все проводки.

                                              Комментарий


                                              • #24
                                                Loo
                                                аналогично и в pResList,
                                                pResList_DepHash
                                                ResourceID, DepHash, SubcontoType, ObjectID

                                                Использовать и индекс и равентсво, все одно, не LIKE.


                                                Ну там не пару байт, но и не смертельно, да и совместимость останется...
                                                С уважением, Максаев Андрей.

                                                Комментарий


                                                • #25
                                                  andrey_seek
                                                  В свое время, еще с Германом Хохловым я обсуждал идею дополнительной таблички с полями типа
                                                  (OperationID, CharType, ResourceID, OperDate, DepartmentID). Каждому субконто присваивается "весовой" коэфициент и выборка происходит по тому заданному субконто из запроса, который имеет наибольший вес. Например, если заданы портфель и бумага, то ходить по бумаге. Согласен, решение не идеальное, но лучше я придумать не смог.
                                                  Кстати, LIKE c константой практически не тормозит.

                                                  Комментарий


                                                  • #26
                                                    loo
                                                    Кстати, LIKE c константой практически не тормозит.
                                                    с какой константой? с такой '%322376%'? в жизни не поверю.

                                                    Комментарий


                                                    • #27
                                                      Loo
                                                      Like в правой части константа?

                                                      да все равно, без индекса - скан таблицы, и однозначно в сад...

                                                      Да и Герман, насколько я знаю, уже не работает там...

                                                      Давайте мериться...

                                                      set nocount on
                                                      delete from pResList where SPId=@@spid

                                                      declare @dd datetime, @dd1 datetime

                                                      select @dd = getdate()

                                                      select getdate() 'Старт'

                                                      declare @i int

                                                      while isnull(@i,0) 2000 begin
                                                      insert into pResList (SPID, ResourceID, DepHash)
                                                      select @@spid, isnull(@i,0), str(isnull(@i,0),15)
                                                      select @i = isnull(@i,0)+1
                                                      end

                                                      select @dd1 = getdate()
                                                      select count(*), @dd1 'Залили pResList', datediff(millisecond,@dd,@dd1) 'Прошло' from pResList where SPId=@@spid

                                                      select count(*) 'Кол-во ЦБ' from tDepartment where SubcontoType = 7

                                                      select count(*), getdate() 'Посчитали LIKE'
                                                      from pResList p (NOLOCK),
                                                      tDepartment d (NOLOCK INDEX=XIE1tDepartment)
                                                      where p.SPID=@@spid
                                                      and d.SubcontoType = 7
                                                      and p.DepHash like d.DepHash

                                                      select datediff(millisecond,@dd1,getdate()) 'Прошло'


                                                      Результат
                                                      Старт
                                                      ------------------------------------------------------
                                                      2002-07-16 15:53:30.247

                                                      Залили pResList Прошло
                                                      ----------- ------------------------------------------------------ -----------
                                                      2000 2002-07-16 15:53:42.483 12236

                                                      Кол-во ЦБ
                                                      -----------
                                                      6429

                                                      Посчитали LIKE
                                                      ----------- ------------------------------------------------------
                                                      0 2002-07-16 15:53:42.497

                                                      Прошло
                                                      -----------
                                                      63606


                                                      С уважением, Максаев Андрей.

                                                      Комментарий


                                                      • #28
                                                        kvit
                                                        Проверил. Чистая задержка составила на нашем сервере составила 2 секунды на 150 тыс. записей. Что гораздо меньше разницы, возникающей при разном уровне использования кэша.

                                                        Комментарий


                                                        • #29
                                                          loo
                                                          Проверил. Чистая задержка составила на нашем сервере составила 2 секунды на 150 тыс. записей. Что гораздо меньше разницы, возникающей при разном уровне использования кэша.
                                                          Не показатель. Фулл скан таблиц никогда не будет быстрее поиска по индексу. При конструкции like '%XXX%' всегда будет фуллскан, чтобы заюзался индекс надо юзать like 'XXX%'

                                                          Комментарий


                                                          • #30
                                                            kvit
                                                            Так хорошего решения, чтобы использовался индекс, пока не предложено.
                                                            andrey_seek
                                                            Константа в like именно на стадии "Залили pResList". В процедуру PosList_Rest она передается параметром и не слишком тормозит (см. выше).
                                                            А вот этого
                                                            and d.SubcontoType = 7
                                                            and p.DepHash like d.DepHash

                                                            делать не стоит. А стоит запустить нашу процедурку и сделать
                                                            and d.SubcontoType = 7
                                                            and p.SecurityID=d.ObjectID

                                                            Комментарий

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

                                                            Свернуть

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

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