Re: IBAnalyst так мелочи
Дайта, пожалуйста, прямую ссылку на новый IBAnalyst, а то версия из ibanalyst2_ru.zip говорит, что уже есть новая версия, и ничего не показывает.
Re: IBAnalyst так мелочи
Dmitri Kuzmenko пишет: IBAnalyst 2.0 - 3000 руб. IBAnalyst 1.95 - бесплатный, все там же, на forum.ibase.ru ссылка. спасибо, понял.
Re: IBAnalyst так мелочи
я все никак не могу затестировать restore, нет у меня реальной базы на 2-5 гиг с большим числом FK, включая плохие. Спроси Коваленко :) А лучше, конечно, попробуй сам У меня уже из памяти все выветрилось :) 2.1 насколько я помню ресторит мою 20 гиговую базу (через сервисы) за 4.5 часа - на час быстрее чем 2.0.1. На гигабайте памяти. Индексы там у меня всякие. В том числе для очень сильно повторяющихся полей. Таблица, относительно которой ориентировались в тестах, содержит (на текущий момент) больше 10 млн записей. Коваленко Дмитрий.
Re: IBAnalyst так мелочи
Hello, Evgeny! Boltik Evgeny wrote: Женя, хелп к IBA надо читать, там объясняется, почему индекс считается плохим. Не, ну я болдею, что ты всех в хелп отправляешь, что тебе новички все. Тут и так понятно, что у тебя и как в программе. да, новички. Хелпом пользоваться не умеют. я по умолчанию скрыл дерево топиков хелпа при его открытии, так его открыть никто не может, видят только контекстный хелп по F1, если вообще читают. Мы обычно пишем программы для людей, а не для себя, что бы по своим принципам судить о происходящем. Интересуют реально не рабочие места в базе, а не все подряд. Я смотрю не я один считаю что желательно было бы выявить индексы ФК и в отдельную их ветку. Мы на то и программисты чтобы программы учить понимать ситуации, а не тупо выводит данные. Программа так и называется Аналитик вот пусть и анализирует кто из индексов кто ;) Еще раз повторяю, что меня не касается что вы там В ЗАПРОСАХ пишете. Индекс с хреновой селективностью может быть ОЧЕНЬ ЗДОРОВО использован в программе. Да еще посмотрел как я делаю замену кодов и нарыл строчку а ты говоришь определить не возможно тип. ;) Жень, у меня софтина не только для Firebird, и не только для тех, кто умеет именовать констрейнты. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: IBAnalyst так мелочи
Hello, Dmitry! Dmitry Yemanov wrote: 2. да, была идея исключать такие индексы из плохих, хотя бы опционально, но начиная с FB 1.5 имя индекса FK/PK формируется по имени constraint, поэтому критерий имя индекса начинается с RDB$FOREING больше не работает. RDB$RELATION_CONSTRAINTS.RDB$INDEX_NAME опция загружать метаданные есть только в IBA 2.0. Короче, ситуация такая: 1. индексы по FK строятся принудительно 2. плохая селективность может быть как у FK так и у любого другого индекса 3. индекс по FK, в отличие от обычного, служит для контроля ссылочной целостности. Поэтому без удаления FK удален быть не может. так что, через RDB$RELATION_CONSTRAINTS.RDB$INDEX_NAME будет возможность показать, что конкретный плохой индекс построен по ПК или ФК для FB 1.5/2.0. Я уже раз десять тут повторял, что понятие плохой связано только с общей селективностью. Если большинство запросов выбирают по такому индексу малое количество ключей, то индекс будет работать БЫСТРО. IBAnalyst не знает и знать не может, какие запросы выполняются в приложениях, и как они используют эти индексы. p.s. спасибо Ded-у за комментарий. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: IBAnalyst так мелочи
Hello, Vlad! Vlad Horsun wrote: по причине очень больших цепочек номеров записей для одного ключа индекса. И что ? если мне память не изменяет, QuickSort плохо сортирует уже сортированные или повторяющиеся значения. Кроме того, у вас там выгрузка из файла сортировки в индекс происходит блоками, что в определенных ситуациях приводит к нехилым тормозам и слабой загрузке процессора. я все никак не могу затестировать restore, нет у меня реальной базы на 2-5 гиг с большим числом FK, включая плохие. Синтетику тестить тоже можно, но это отдельный разговор. А это нужно спросить у того, кто знает, какой метод сортировки использует птичка при построении индекса ;) До ОДС 11 цепочки дубликатов не сортируются и новые номера записей вставляются на первое место это уже другой вопрос, т.к. влияет на скорость сборки мусора в индексе. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: IBAnalyst так мелочи
Dmitri Kuzmenko ... Hello, Vlad! Vlad Horsun wrote: по причине очень больших цепочек номеров записей для одного ключа индекса. И что ? если мне память не изменяет, QuickSort плохо сортирует уже сортированные или повторяющиеся значения. Да, наш модуль сортировки не самым лучшим образом работает с повторяющимися значениями. Но в FB2 ему на вход подаются не только ключи записей, но и номера записей, что полностью исключает повторение сортируемых значений. Это для построения индексов. Для order by\group by это было так всегда. Единственное известное мне исключение - сортировка для distinct. В случае сортировки для индекса в FB 1.x замедление будет иметь место только если эти одинаковые значения совпадают с физическим порядком чтения записей из таблицы. Ибо quicksort'ом сортируются небольшие группы записей, а не вся таблица целиком. Далее - сортировка слиянием, у которой нет такого недостатка. Кроме того, у вас там Это у кого- у вас ? :) выгрузка из файла сортировки в индекс происходит блоками, что в определенных ситуациях приводит к нехилым тормозам и слабой загрузке процессора. Не совсем так. я все никак не могу затестировать restore, нет у меня реальной базы на 2-5 гиг с большим числом FK, включая плохие. Спроси Коваленко :) А лучше, конечно, попробуй сам Синтетику тестить тоже можно, но это отдельный разговор. А это нужно спросить у того, кто знает, какой метод сортировки использует птичка при построении индекса ;) До ОДС 11 цепочки дубликатов не сортируются и новые номера записей вставляются на первое место это уже другой вопрос, т.к. влияет на скорость сборки мусора в индексе. И на скорость вставки ключа в индекс. При обычной работе. И вообще - кто меня сначала длинными цепочками с толку сбил ? :) -- Хорсун Влад PS Реальная БД : ОДС 10.1, таблица 1798843 записей, 2 индекса : а) PK - INT, селективность 5.55915676159202E-7 б) IDX - INT селективность 0.01351 Создание индексов, мс : FB 1.5.2Ya 892FB 2.0FB 2.1IB 7.5.1 PK 8352 7461 7040 6149 9353 IDX 13580 11106 7451 6990 10685
Re: IBAnalyst так мелочи
Hello, Ded! You wrote on Sat, 19 May 2007 14:34:25 +0400: 3. IBA показывает плохие индексы. В хелпе написано, что такое плохие. И IBA не предлагает удалять такие индексы. D Дим, напиши большими буквами при старте, что запуск IBA не D требует обязательного одновременного отключения Human Brain. D Всё на свете одновременно и полезно и вредно. Мы ж не отказываемся D от употребления писчи, хоть это и ведёт к некоторым негативным D процессам в организьме. D Для того, чтобы чего-то достичь, надо за это чем-то заплатить, это D ж ясно даже пьяному ежу. Если приоритет цели Ссылочная D целостность данных выше приорета Скорость выполнения D некоторых запросов и действий, то он выше и за него платим D именно этим. Причём большинство запросов можно и подрулить D по месту. Причёи если заранее знаешь, что индекс для запроса D плохой, то сразу, не доводя до стадии острого натурного экскремента. D Для чего про этот индекс и пишут на заборе. D Специально для взрослых самцов гомосапиенса. Дима Диме на форуме написал какой ты колючий. :) Какой тогда Ded? Бугага. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixangry_dogtndottobdotru
Re: IBAnalyst так мелочи
Hello, Evgeny! Boltik Evgeny wrote: Тут решил посмотреть что у одного клиента с базой творится жуткие тормоза случаются и закачал прогу. Дима извени но скаких пор ФК стали плохими индексами это получается логику перенисти в триггер и удалить индекс ;) Я думаю тогда сервер при добавлении данных и удалении загнется :) т.к. будет натурал Женя, хелп к IBA надо читать, там объясняется, почему индекс считается плохим. Может не обращать внимание на такие индексы при анализе ну тоесть не говорить что они плохие без них то нникак. нельзя. потому что индексы с плохой селективностью, а особенно FK, по крайней мере до FB 2 сильно тормозят restore. И вообще, фиговая селективность индекса всегда фиговая, FK это или нет. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: IBAnalyst так мелочи
Hello, DmitryLe! DmitryLe wrote: Я про это говорил с самого начала победного наступления сапогом на статистику. Дима смотрит на FK не как разработчик, а как менеджер на график. продаж :-))) Без обид. :-))) не совсем так. 1. индекс это индекс, по ФК он построен или нет. 2. да, была идея исключать такие индексы из плохих, хотя бы опционально, но начиная с FB 1.5 имя индекса FK/PK формируется по имени constraint, поэтому критерий имя индекса начинается с RDB$FOREING больше не работает. 3. IBA показывает плохие индексы. В хелпе написано, что такое плохие. И IBA не предлагает удалять такие индексы. Вот тут http://forum.ibase.ru/phpBB2/viewtopic.php?t=516highlight= тут все правильно. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: IBAnalyst так мелочи
Hello, Evgeny! Boltik Evgeny wrote: Дима извени но скаких пор ФК стали плохими индексами это получается логику перенисти в триггер и удалить индекс ;) Я думаю тогда сервер при добавлении данных и удалении загнется :) т.к. будет натурал IBA где-нибудь предлагает удалять такие индексы? Цитирую хелп: 7. Почему индексы названы плохими? Индексы, имеющие критическую селективность (ниже 0.01) IBAnalyst называет плохими по нескольким причинам: - Селективность (избирательность) такого индекса ниже той, которая используется оптимизатором (константа 0.01). Теоретически оптимизатор не должен использовать такой индекс, тем не менее использует, если ничего другого нет. - Такой индекс приводит к очень медленной сборке мусора. Данная проблема решена только в InterBase 7.1/7.5, и будет решена в Firebird 2.0 - Такие индексы сильно замедляют процесс restore, и вообще сами по себе создаются долго (create/alter index active), по причине очень больших цепочек номеров записей для одного ключа индекса. - Если этот индекс используется в where для проверки на неизвестное значение (по которому много дубликатов ключа), то есть шанс что его использование приведет к сильному потреблению памяти на хранение большого количества ссылок на записи - Если такой индекс используется в order by, и дубликатов меньших значений больше (т.е. тех, которые располагаются в начале индекса), то будет много чтений страниц с диска, что ухудшит скорость выборки. - IBAnalyst не может не сигнализировать о наличии таких индексов. Худшим случаем плохого индекса является индекс со большим количеством ключей и значением 1 в Uniques, то есть с всего одним единственным значением ключа (см. Бесполезные индексы на странице Общая информация IBAnalyst). -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: IBAnalyst так мелочи
Dmitri Kuzmenko ... - Такие индексы сильно замедляют процесс restore, и вообще сами по себе создаются долго (create/alter index active), Вот об этом - впервые слышу. Хотелось бы подробнее по причине очень больших цепочек номеров записей для одного ключа индекса. И что ? И вообще - чем более селективен индекс, тем больше места он занимает на диске :-P -- Хорсун Влад
Re: IBAnalyst так мелочи
Vlad Horsun wrote: - Такие индексы сильно замедляют процесс restore, и вообще сами по себе создаются долго (create/alter index active), Вот об этом - впервые слышу. Хотелось бы подробнее Это есть факт, мистер Дюк (С) :) Во всяком случае, до 1.5.x включительно. по причине очень больших цепочек номеров записей для одного ключа индекса. И что ? А это нужно спросить у того, кто знает, какой метод сортировки использует птичка при построении индекса ;) -- Regards. Ded.
Re: IBAnalyst так мелочи
Dmitri Kuzmenko wrote: 3. IBA показывает плохие индексы. В хелпе написано, что такое плохие. И IBA не предлагает удалять такие индексы. Дим, напиши большими буквами при старте, что запуск IBA не требует обязательного одновременного отключения Human Brain. Всё на свете одновременно и полезно и вредно. Мы ж не отказываемся от употребления писчи, хоть это и ведёт к некоторым негативным процессам в организьме. Для того, чтобы чего-то достичь, надо за это чем-то заплатить, это ж ясно даже пьяному ежу. Если приоритет цели Ссылочная целостность данных выше приорета Скорость выполнения некоторых запросов и действий, то он выше и за него платим именно этим. Причём большинство запросов можно и подрулить по месту. Причёи если заранее знаешь, что индекс для запроса плохой, то сразу, не доводя до стадии острого натурного экскремента. Для чего про этот индекс и пишут на заборе. Специально для взрослых самцов гомосапиенса. -- Regards. Ded.
Re: IBAnalyst так мелочи
Ded ... Vlad Horsun wrote: - Такие индексы сильно замедляют процесс restore, и вообще сами по себе создаются долго (create/alter index active), Вот об этом - впервые слышу. Хотелось бы подробнее Это есть факт, мистер Дюк (С) :) Во всяком случае, до 1.5.x включительно. Не наблюдал. Но проверю. по причине очень больших цепочек номеров записей для одного ключа индекса. И что ? А это нужно спросить у того, кто знает, какой метод сортировки использует птичка при построении индекса ;) До ОДС 11 цепочки дубликатов не сортируются и новые номера записей вставляются на первое место -- Хорсун Влад
Re: IBAnalyst так мелочи
Dmitri Kuzmenko wrote: 2. да, была идея исключать такие индексы из плохих, хотя бы опционально, но начиная с FB 1.5 имя индекса FK/PK формируется по имени constraint, поэтому критерий имя индекса начинается с RDB$FOREING больше не работает. RDB$RELATION_CONSTRAINTS.RDB$INDEX_NAME -- Дмитрий Еманов
Re: IBAnalyst так мелочи
Может не обращать внимание на такие индексы при анализе ну тоесть не говорить что они плохие без них то нникак. Лучше уж чтобы FK без индексов появился. Я вот тоже с этим делом воюю через одно место - индексы композитные, триггеры, чеки :-(
Re: IBAnalyst так мелочи
Дима извени но скаких пор ФК стали плохими индексами это получается логику перенисти в триггер и удалить индекс ;) Я думаю тогда сервер при добавлении данных и удалении загнется :) т.к. будет натурал Может не обращать внимание на такие индексы при анализе ну тоесть не говорить что они плохие без них то нникак. Я про это говорил с самого начала победного наступления сапогом на статистику. Дима смотрит на FK не как разработчик, а как менеджер на график. продаж :-))) Без обид. :-))) Вот тут http://forum.ibase.ru/phpBB2/viewtopic.php?t=516highlight= Дмитрий
