Bankir.Ru
10 декабря, суббота 17:45

Объявление

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

Diasoft 5nt. 3.4.5

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

  • Diasoft 5nt. 3.4.5

    Начну в новом треде.
    Обратите внимание, что при переходе на 3.4.5 у вас удалится DispatchUser_Proc. Так что сохраните все свои наработки иначе...
    Изменения произошли благодаря тому что в эту процедуру наконец-то затащили @OperSetID. Теперь диспатчи даже можно из функций вызывать .

  • #2
    Слушок ходит, что 3.4.5 вообще не хотят запускать в эксплуатацию, а рекомендуется переход на планируемую 3.5 Никто об этом не слышал?

    Комментарий


    • #3
      ZON
      Слушок ходит, что 3.5.1 не будут запускать в эксплутацию (3.5 ровно вообще не будет), она будет промежуточной. Я думаю, что они в Диасофте сами еще ничего не решили.

      Комментарий


      • #4
        не знаю что и когда будут запускать в ксплуатацию, но что то 3.4.5 мне не особо понравился, слишком много (особенно было заметно на внебиржевом рынке) что было исправленно в 3.4.4 не попало в 3.4.5

        Комментарий


        • #5
          Еще одна бяка. Правда я думаю многих (если не всех) это не коснется.
          Глючит интерфейс исполнения обязательств в ОФБУ.

          Комментарий


          • #6
            Вообще 3.4.5 build 37 - уже кое-что Сегодня я на боевом уже на 3.4.5

            Комментарий


            • #7
              Все 3.4.5 почти прижилось. Как сказал Диасофт мы первый банк на этом релизе.
              Ну а теперь вопрос поделитесь пожалуйста инфой, у кого сколько записей в tDealProtocol (select count(1) from tDealProtocol (nolock)), а то одна проблема тут назревает...

              Комментарий


              • #8
                Есть статистика: два банка примерно с одинаковыми оборотами и возрастом базы около двух лет: 4,1-4,5 млн. записей. Банк с оборотами на порядок больше и возрастом базы 7 месяцев (с начала 2002) - 2,5 млн. записей.

                Комментарий


                • #9
                  у нас 3,9 записей в tDealProtocol. При этом средний прирост 25000 записей в день (катастрофа ). У меня складывается ощущение, что это происходит из-за крыжика "архив" в отчетах. А так как отчетов у нас много и записей о них также много, возникает проблема переполнения tDealProtocol. Сейчас интерфейс открытия сделок биржевых отрабатывает 1,5 мин. У нас правда записей в tDeal около 500 тыс.

                  Комментарий


                  • #10
                    kvit
                    На сколько я слышал в 3.4.5 предусмотрена архивация и очистка протоколов, что позволит усечь tDealProtocol?правда по моему сыровато еще.

                    Комментарий


                    • #11
                      У нас tDealProtocol ок. 6,8 млн., прирост 6-10 тыс./день.

                      А реально кто-нибудь использует диасофтовскую архивацию?

                      Комментарий


                      • #12
                        ASar
                        А реально кто-нибудь использует диасофтовскую архивацию?
                        я не использую и пока не планирую...
                        У нас tDealProtocol ок. 6,8 млн.,
                        Ни фига себе... И как долго открывается окно биржевых сделок?...

                        Комментарий


                        • #13
                          kvit
                          При этом окно биржевых сделок открывается примерно за 5 секунд(но мы в этом плане не показатель, т.к. возможности биржевого модуля используем процентов на 10, он у нас закуплен усеченный). Основные проблемы при редактирование курсов валют, там идет запрос в tAudit и данный запрос может отрабатывать в течении 30 минут.

                          А на фига Вы выставляете крыжик архив в отчетах?

                          Комментарий


                          • #14
                            ZON
                            А на фига Вы выставляете крыжик архив в отчетах?
                            Старые проблемы... Без него у нас раньше некорректно разбивались отчеты на отдельные файлы. Сейчас помоему и без него все ок. Но архивацию планируем использовать очень активно. Лучше выполнить просмотр архива и распечатать (просмотреть) файл, который уже находится на диске, чем нагружать sql сервер еще раз.

                            Комментарий


                            • #15
                              kvit
                              А что у Вас работа отчетов отнимает очень много ресурсов? Не проше ли прооптимизировать отчеты, а для работы с архивом оставить только наиболее трудоемкие, таких от силы процентов 5?

                              Комментарий


                              • #16
                                ZON
                                А что у Вас работа отчетов отнимает очень много ресурсов?
                                смотря какие... по большому счету только отчеты и занимают много времени и ресурсов... или у Вас сервер загружен другими работами, если да - то какими?

                                Комментарий


                                • #17
                                  kvit
                                  Основную загрузку поддают загрузки(филиальных данных и т.п.), закрытие дня. Отчеты то же занимали значительную часть ресурсов до тех пор пока мы их не прошерстили и не прооптимизировали. С сохранением результатов работы отчетов в архив у нас работает от силы десяток наиболее трудоемких отчетов, а у остальных время работы составляет до 10 секунд, поэтому проще их построить заново(да и более корректно, т.к. данные могли устареть). Если у Вас есть серьезные проблемы с торможением отчетов, то это может быть также связано с тем, что они некорректно разнесены по группам.

                                  Комментарий


                                  • #18
                                    ZON
                                    Основную загрузку поддают загрузки(филиальных данных и т.п.), закрытие дня.
                                    У нас это вообще не выполняется (в том понимание, как это должно происходить, так как у нас не внедренно РКО). Основные торможения у нас это именно отчетность так как ее уйма и достаточно много заложено аналитики. Загрузки как раз для нас не так критичны (например загрузка около 1000 сделок с ММВБ у нас занимает менее 20 минут, да и то это происходит в автомате ночью).
                                    Если у Вас есть серьезные проблемы с торможением отчетов, то это может быть также связано с тем, что они некорректно разнесены по группам.
                                    не понял чем вызвана данное заключение...

                                    Комментарий


                                    • #19
                                      kvit
                                      Просто если у Вас довольно большие группы пользователей и одновременно запускается один образец отчета несколькими пользователями из одной группы и в данном отчете используются промежуточные таблицы, то время работы такого отчета увеличивается как минимум в двое. А как вы работаете без РКО? У Вас только один модуль какой-то закуплен?

                                      Комментарий


                                      • #20
                                        ZON
                                        А как вы работаете без РКО? У Вас только один модуль какой-то закуплен?
                                        У нас внедрено ОФБУ, векселя, Дилинг (биржа, конверсия, мбк), биржа, внебиржа. Все используется достаточно серьезно, вот и задумываемся над РКО. Вместо РКО 5nt у нас используется 4x4.
                                        Просто если у Вас довольно большие группы пользователей и одновременно запускается один образец отчета несколькими пользователями из одной группы и в данном отчете используются промежуточные таблицы, то время работы такого отчета увеличивается как минимум в двое
                                        Опять не понимаю почему Вы думаете что это из-за групп. Просто взаимные блокировки imho...

                                        Комментарий


                                        • #21
                                          Согласен, что немного некорректно выразился блокировки не зависят от групп, я имел ввиду что если отчеты криво разбросаны по группам, то данные можно получить не совсем коректные.
                                          А если у Вас много долгоиграющих аналитических отчетов то может быть имеет смысл использовать технологию формирования отчетности на резервном сервере StandBy, что позволит разгрузить основной сервер. В свое время мы смотрели их решение, но оно было еще сыровато возможно сейчас уже доработали.

                                          Комментарий


                                          • #22
                                            ZON
                                            использовать технологию формирования отчетности на резервном сервере StandBy
                                            уже задумываемя над этим. правда Диасофт пропагандирует это все для Sybase, а у нас MS SQL. Но по сути технология единая. Но к сожалению не все можно отдать на откуп StandBy. У нас ежедневно делается несколько отчетов по горячим данным и с достаточно сильной аналитикой Вот тут и затык. Ну да ладно - сейчас ведем работы (совместно с диасофтом) по ускорению работы интерфейса биржевых сделок...

                                            Комментарий

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

                                            Свернуть

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

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