Bankir.Ru
6 декабря, вторник 15:24

Объявление

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

Засада

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

  • Засада

    Перешли на 8.500 с 8.320

    Потратил пол дня борясь с ветряными мельницами ...

    Оказалось что в 8.500 строка болле 255 символов обрезается, тогда как в 8.320 программы выдавала сообщение об ошибке ...

  • #2
    RedPank
    А можно уточнить в каком алгоритме ?

    Комментарий


    • #3
      Изменился порядок контроля за длиной строк. Во всех алгоритмах, написанных на Atlantis. Если раньше при вводе слишком длинной строки Вы получали предупреждение, то сейчас Вы получите обрубленные данные

      Комментарий


      • #4
        А вот есче ЗАСАДА

        Изменился индекс IACC_AccCurr в таблице Accounts. Так что все отчеты используещие этот индекс перестанут работать ....

        P.S.
        IACC_AccCurr = AccNum(unique,seg),CurrCode(seg),NewAccNum

        Какого хрена добавили NewAccNum в конец ??? Что-ж теперь AccNum(unique,seg),CurrCode(seg) уже на обеспечивают уникальности ? Но это-же полный gbpltw.

        Комментарий


        • #5
          RedPank
          Вполне возможно, что многие запросы наоборот будут работать оптимальнее, т.к. оптимизатор Оракла будет их выполнять исключительно по индексу. Например огромное число запросов
          select newaccnum from accounts where accnum=... and currcode=....
          Оракл 9 при этом работает сильно оптимальнее, про 8 точно не знаю. Страшного ничего в этом нет.

          Комментарий


          • #6
            select newaccnum from accounts where accnum=... and currcode=....


            И так работает. Ему NewaccNum не нужен.
            Имеет смысл только запрос
            select newaccnum from accounts where accnum=... and currcode=.... and NewAccNum = ...
            Но это уже масло-масленное, т.к. AccNum вместе с Currcode = NewAccNum

            Комментарий


            • #7
              RedPank
              Ты не прав. Ты исходишь из логики Битрива. Оракл может работать и по другому. Если к первому запросу прибавить другой
              select accnum, currcode from accounts where newaccnum=....... то и первый запрос и второй будут выполняться по одному и тому же индексу.
              В Оракл 9 появился инструмент, который анализирует реальные запросы, их планы выполнения, количество и дает рекомендации по оптимизации запросов и индексов. Так вот он сказал, что нужен такой индекс, при этом сортировки многие будут выполняться не по таблице а по индексу, что дешевле и быстрее.

              Комментарий


              • #8
                arc Ты исходишь из логики Битрива Обидел ...

                Я не говорю о том что индекс по NewAccNum не нужен ораклу !
                Но если ты посмотришь на словарь, то увидешь, что NewaccNum присутствует есче в

                AccbyNewAccNum
                AccbyOpenCurrNewNum
                AccTrNewNum

                Не многовато-ли ? Oracle просто заоптимизируется !!!
                [/I]

                Комментарий


                • #9
                  RedPank
                  Ты исходишь из логики Битрива Обидел ... Ей богу не хотел !
                  Сейчас посмотрел Навигатор : только два индекса дублируют друг друга
                  ACCBYNEWACCNUM и IACC_NEWACC. Есть еще IACC_ACCCURR, но надо анализировать запросы - можно ли его убрать.
                  Остальные для своих нужд, в них Newaccnum в последних сегментах и видимо запросы могут его не содержать.

                  Комментарий


                  • #10
                    Блин .... мы тут разговариваем о разном.
                    Индекс, который виден в ORACL это не вседа тот индекс, который виден атлантису. Не надо забывать, что атлантис использует Flat поля как свои индексы для навигации. А я то говорил именно об индексе из атлантиса.

                    Комментарий


                    • #11
                      RedPank
                      Атлантис использует не Flat поля, а индексы по Flat полям. Чувстуешь разницу ? Никаких СВОИХ индексов у Атлантиса нет - это именно Оракловые индексы. Flat поля изначально предназначались для интерфейсов (спасибо Ерошину) и использовались также в первоначальной серверной логике. Сейчас в логике новой они не используются, многие вобще были убраны в последующих версиях. Я не вижу причин для волнения, кроме того, что индексов много. Это действительно не гуд, но не смертельно. Логика БД не нарушается. Вот когда к полям в индексе добавляют btrv_address и говорят, что он уникальный, вот тогда это мина, которая может взорваться в любую секунду и задвоить сущности БД, т.к. уникальность индекса не отследит эту ситуацию.

                      Комментарий


                      • #12
                        arc Во блин достал ... Да знаю как все это работает! Не надо мне обяснять.

                        А вот есче ЗАСАДА

                        Изменился индекс IACC_AccCurr в таблице Accounts. Так что все отчеты используещие этот индекс перестанут работать ....

                        Это относиться к АТЛАНТИСУ !!!!!!!!!!!!!!!!!!!!!!

                        Комментарий


                        • #13
                          arc
                          прошу меня простить за излишюю грубую эмоциональность. Погорячился.

                          Комментарий


                          • #14
                            RedPank В качестве комментария: если отчеты писать на PL\SQL, то сразу становится по-барабану, что там Кворум творит с индексами (влияет на размер базы): в любой момент можно как "нарисовать свой" и прописать соответствующий хинт, если что-то не устраивает, так и отказаться от него, если появится Кворумоский аналог...

                            Комментарий


                            • #15
                              sprut Это ясно. Но я не придерживаюсь мнения Кворума, что все надо затолкать на сервер.
                              Причина: Невозможно изменить скрипт на сервере во время рабочего дня.
                              Отчеты критичные по скорости - да, но остальное пусть останется на клиенте ...

                              Комментарий


                              • #16
                                RedPank Но я не придерживаюсь мнения Кворума, что все надо затолкать на сервер А я не говорил, что надо просто использовать использовать Кворумовские отчеты: беда в том, что большинство переносимых на сервер отчетов реализовано в духе Btrive подхода. Я говорил о том, что "писать" надо на PL\SQL, когда необходимые данные можно выдернуть одним-двумя оптимизированными запросами...

                                Комментарий

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

                                Свернуть

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

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