Проблемка с пееркомпилляцией процедур в FB2
В общем в FB2 если я создаю процедуру типа такой: CREATE PROCEDURE TEST AS BEGIN EXECUTE STATEMENT NULL; END потом вызываю её, получаю ошибку. Делаю комит или роллбэк и пытаюсь перекомпиллировать процедуру например на такую: CREATE PROCEDURE TEST AS BEGIN EXECUTE STATEMENT ''; END и получаю: This operation is not defined for system tables. unsuccessful metadata update. object TEST is in use. Кто в этом виноват? Эксперт или сервер?
Re: ������� � ������� (������ ������������)
Hello, Дмитрий! Дмитрий Студинский wrote: where ((FTI.Files_Type between 10 and 19) or (FTI.Files_Type between 30 and 39)) При этом строится план (Имя индекса = IX_ИмяТаблицы_ИмяПоля) PLAN JOIN (F NATURAL,FP INDEX (IX_FILES_PUBLISHER_file_id),FTI INDEX (IX_FILES_TYPE_ID_file_id,IX_FILES_TYPE_ID_files_type,IX_FILES_TYPE_ID_files_type)) оптимизатор из-за OR взял IX_FILES_TYPE_ID_files_type два раза, должен выбрать множества ключей и слить их по OR. Если Прописываю план PLAN JOIN (F NATURAL,FP INDEX (IX_FILES_PUBLISHER_file_id),FTI INDEX (IX_FILES_TYPE_ID_file_id)) Полная выборка занимает 2сек то получается, что именно оно и виновато. Пока что в условиях прописал FTI.Files_Type + 1. Но хотелось бы услышать почему сервак так начинает мучаться? Может вообще удалить ненужные индексы? ЗЫ Версия сервера 1.5.3.4870 Статистика по индексам это если ты недавно set statistics index делал. IX_FILES_TYPE_ID_files_type = 0,011494252830744 не фонтан. IBAnalyst тебе лучше скажет, нормальный это индекс или нет. В целом нет, особенно если в between много ключей попадает, да еще и по or. Так что ты +0 правильно сделал. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Интересный эффект на свежезалитых таблицах
Пронаблюдал однако. В процессе очередной революции по преодолению у себя в базе грехов молодости создал несколько новых табличек. В том числе две толстеньких - 1 194 571 и 3 583 713. Сразу с констрайнтами и индексами создал, а потом заполнил посредством специяльно сделанной для того процедурки. Чиста инсёртами, без всяких там мусоропорождающих извращений. Стал запросики писать. Простенький иннер джойн этих двух с коротким справочником. С ордер-планом по деск-ПК самой жирной и присоединением по ПК второй и справочника тоже по ПК ессно. Вроде работает приемлемо. Однако. Вставил после этого ещё одну запись в миллионник и три в трёхмиллионник, выполняю тот же запрос, который на эти записи со своим ордер-планом просто обязан наступить манаганавенно - и опаньки, жду больше минуты. Корячу запрос чтоб план поменять так и эдак - всё неладно получается. Стал чесать репу, писать грозно-слёзное письмо ДЕ, попутно для понятности исследовать распределение значений в индексах путём сборки мощнейщих агрегатов в этих таблицах, макс-мин-каунт с группировкой, загрузил сервак по полной, думал уже завалить, но таки дождался. И что? После сборки этих агрегатов исходный запрос полетел мухой... И что это было, Берримор? Кеш не катит - 1К страниц и стало работать быстро не только в этом соединении (классика). Файловый кеш оси? Так страницы с новыми записями там должны были оказаться сразу после первого исполнения запроса. А точнее, сразу после вставки. Не поленился, отцепился, поселектил целиком широкий миллионник из другой базы, чтоб наверняка всё своё вытеснить (еще мин 10 покурил). Прицепился - летает, падло. Остаётся всё-таки только какое-то упорядочивание чего-то у базы внутрях после массированного фетча этих таблиц. Вот только чего - мусора-то быть не должно от инсёртов-то... Мож в индексах что? После массированной вставки при живых индексах что-то там в носе не кругло получается что ли? В непонятках я весь... И мысли об достоверности TPC-чего-то-тестов на свежезалитых базах мелькают. Что-то перекликается в подкорке с тем, что Влад говорил про упорядоченность страниц, но как-то вяло перекликается - что ж они, после фетча разупорядочились что ли? -- Regards. Ded.
Re: Интересный эффект на свежезалитых таблицах
Иззиняюсь. Вдогонку - это 1.5.3. -- Regards. Ded.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: По поводу косяка с массовым обновлением lineitem на ASA9 - виноваты индексмы. Т.е. это явные грабле в ASA. Нашли способ как сократить это до 67 минут только настройками параметров. Виновата частая запись грязных страниц по причине слишком короткого интервала допустимого восстановления базы после сбоя. Не сказал бы что грабли, слишком специфичная задача. Тотже Ya отработал запрос за пару минут, А вот это интересно, за счет чего такая резвость? Forced writes? Дилетантский вопрос: а не связано ли как-то замедление подобной операции у других серверов по сравнеию с FB с тем, что есть затраты на обеспечение той самой пресловутой Statement/transaction consistency? MS копался раздувая лог 1 час, ORA выполнил быстрее Быстрее чем MS или быстрее Ya? На этом тестирование заканчиваю. Положительный эффект есть - пару косяков в FB2 подправили. А какими еще тестами пользуетесь в работе кроме TPC-R?
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! интересуют также конечные размеры БД (м.б. плюс лог) после заливки данных в БД. а также перечень параметров конкретных серверов, что было изменено в отношении значений по умолчанию (например для ASA?). -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: Интересный эффект на свежезалитых таблицах
Ded ... Пронаблюдал однако. В процессе очередной революции по преодолению у себя в базе грехов молодости создал несколько новых табличек. В том числе две толстеньких - 1 194 571 и 3 583 713. Сразу с констрайнтами и индексами создал, а потом заполнил посредством специяльно сделанной для того процедурки. Чиста инсёртами, без всяких там мусоропорождающих извращений. Стал запросики писать. Простенький иннер джойн этих двух с коротким справочником. С ордер-планом по деск-ПК самой жирной и присоединением по ПК второй и справочника тоже по ПК ессно. Вроде работает приемлемо. Однако. Вставил после этого ещё одну запись в миллионник и три в трёхмиллионник, выполняю тот же запрос, который на эти записи со своим ордер-планом просто обязан наступить манаганавенно - и опаньки, жду больше минуты. Статистики выполнения конечно не осталась ? Корячу запрос чтоб план поменять так и эдак - всё неладно получается. Стал чесать репу, писать грозно-слёзное письмо ДЕ, попутно для понятности исследовать распределение значений в индексах путём сборки мощнейщих агрегатов в этих таблицах, макс-мин-каунт с группировкой, загрузил сервак по полной, думал уже А в это время кто-то тоже грузил сервер по-полной ? :) завалить, но таки дождался. И что? После сборки этих агрегатов исходный запрос полетел мухой... И что это было, Берримор? А тут Берримор отстал от сервера ? ;) ... Что-то перекликается в подкорке с тем, что Влад говорил про упорядоченность страниц, но как-то вяло перекликается - что ж они, после фетча разупорядочились что ли? Не, имхо, тут что-то другое... -- Хорсун Влад
Re: ���������� ������ �� ������������ �������
завалить, но таки дождался. И что? После сборки этих агрегатов исходный запрос полетел мухой... И что это было, Берримор? Интересно. На Ya 889 примерно такая же ситуевина. В январе сего года вычистил из базы данные 2002 и 2003 года. Дирик возмутился. Нужен ему понимаешь сравнительный анализ. Залил в зад три таблицы 16 млн., 9 млн., и 6 млн. Пересчитал ВСЕ индексы. Сервер при селектах из этих таблиц вставал колом на 20-30 мин. К вечеру эти же селекты стали выполняться за 8-10 мин. Похоже данные отлежались, притерлись, а сервер очухался от встряски. Ближе к ночи сделал b/r и все залетало 0,5-3 мин. С уважением, Артур Галимов.
Re: ���������� ������ �� ������������ �������
Привет. Абижаишь :) Тем не менее, статистика-то, как я её понимаю, влияет на выбор плана, а не на выполнение запроса. А тут препарилось мнговенно и правильно, а вот выполнялось - ... По моим наблюдениям, индекс отстает. Такое складывается впечатление. Я тоже недавно переливал данные. Таже картина. Помог пересчет статистистики. Дмитрий
Re: Интересный эффект на свежезалитых таблицах
Не, это не боевой сервер. Борьбу с запросом начал вчера ночером, НОЧЕРОМ это типа TONIGHT ? ;-)))
Re: Интересный эффект на свежезалитых таблицах
Dmitry Lendel wrote: Абижаишь :) Тем не менее, статистика-то, как я её понимаю, влияет на выбор плана, а не на выполнение запроса. А тут препарилось мнговенно и правильно, а вот выполнялось - ... По моим наблюдениям, индекс отстает. Такое складывается впечатление. Я тоже недавно переливал данные. Таже картина. Помог пересчет статистистики. Аднака вы оба правы. Я помнил, что статистику пересчитывал, но, как всегда, оказалось что не ту, не там и не тогда. Я это сделал действительно после заливки, но потом мы с Алексом ту базу успешно заломали насмерть совместными усилиями по одновремённой правке метаданных и выполнения кое-каких DML-операторов. Выкинули и сделали по очереди чего надо было на свежей копии. И тут я уже, похоже, про статистику-то забыл, пустая. Пересобрал, но сейчас уже особого эффекта не обнаружил. Проверю в другой раз. Однако, интерес к тому, что почему после ативного фетча наступает улучшение без пересчёта, остаётся в силе. И тогда уж до кучи, ещё вопрос к ведущим птицеводам - а что такое делает этот пересчёт кроме установки значений в системных таблицах? И почему он висит очень долго на длинных таблицах, причём не на выполнении, а на коммите? Чую печёнкой, что-то интересненькое узнаем :) -- Regards. Ded.
Re: Проблемка с пееркомпилляцией процедур в FB2
s Кто в этом виноват? s Эксперт или сервер? Не-а. ???
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Alexander Goldun tmpmail1-P4MSZbKTW1ZxeeU/[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Дилетантский вопрос: а не связано ли как-то замедление подобной операции у других серверов по сравнеию с FB с тем, что есть затраты на обеспечение той самой пресловутой Statement/transaction consistency? Ora тоже пару минут выполнял. MS копался раздувая лог 1 час, ORA выполнил быстрее Быстрее чем MS или быстрее Ya? Как Ya. А какими еще тестами пользуетесь в работе кроме TPC-R? Комплексное тестирование проводил только TPCR. А так у меня есть апака со сборником косяков -)
Re: Интересный эффект на свежезалитых таблицах
Ded [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] этот пересчёт кроме установки значений в системных таблицах? И почему он висит очень долго на длинных таблицах, причём не на выполнении, а на коммите? Чую печёнкой, что-то интересненькое узнаем :) Транзакционные пулы умирают :-)
OFF Хотя сегодня не пятница
http://rsdn.ru/forum/?mid=1705591
Re: OFF Хотя сегодня не пятница
http://rsdn.ru/forum/?mid=1705591 случайно, не тот клиент, что базу на флешке держал? :)
