FB 1.5 - 2.1
Допустимо ли повторное выполнение команды обновления метаданных?
select * from rdb$fix_metadata('WIN1251');
А то у меня первый запуск завершился ошибкой из-за наличия параллельного
коннекта к базе :-(
Re: FB 1.5 - 2.1
24.09.2010 12:04, Konstantin R. Beliaev пишет:
Допустимо ли повторное выполнение команды обновления метаданных?
select * from rdb$fix_metadata('WIN1251');
А то у меня первый запуск завершился ошибкой из-за наличия параллельного
коннекта к базе :-(
Если ты зароллбечился после ошибки, то повторяй снова. Это же обычный SQL.
--
Дмитрий Еманов
Re: FB 1.5 - 2.1
Dmitry Yemanov wrote:
24.09.2010 12:04, Konstantin R. Beliaev пишет:
Допустимо ли повторное выполнение команды обновления метаданных?
select * from rdb$fix_metadata('WIN1251');
А то у меня первый запуск завершился ошибкой из-за наличия параллельного
коннекта к базе :-(
Если ты зароллбечился после ошибки, то повторяй снова. Это же обычный SQL.
К сожалению, это был скрипт, в котором стоял коммит :-(
Как изменить хранимку, чтобы апдейтились только структуры, в которых не
установился чарсет?
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Tue, 16 Sep 2008 10:47:10 +0400: Ого, спасибо, проверим :) DY Т.к. снапшоты еще не ожили, то могу собрать вам 2.1 или 2.5 с фиксом и DY выслать. Дай знать, если интересно. Но хотелось бы проверить фикс DY именно на оригинальной базе, а не на твоей тестовой. Конечно интересно, проверим на оригинальной. Если не очень сложно, то лучше 2.1. Тогда, насколько я понимаю, b/r не нужен будет. Проверить только тот конкретный запрос, или еще на что-то обратить внимание? -- -=Оказывается, спать 4 часа в сутки не сложно. Сложнее не спать 20.=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Tue, 16 Sep 2008 11:56:15 +0400: Если не очень сложно, то лучше 2.1. DY Супер или классик? Классик. Проверить только тот конкретный запрос, или еще на что-то обратить внимание? DY Как минимум тот запрос. Но лучше погонять этот билд и на других DY запросах - в целом лучше станет или хуже. Я думаю, у них не одна DY претензия была. Да и проверить, чтобы остальное не отвалилось :-) Ок. -- -=Hе надо злиться... Hадо МСТИТЬ!=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitri! You wrote on Thu, 11 Sep 2008 19:12:14 +0400: DK кстати, где расклад по времени, что такая выборка тормознее? Тормознее, т.к. маленькая таблица, когда была основной, очень урезала выборку. Но относится ли этот случай к тем, которые должен разрулить оптмизатор в нынешнем виде - хз. DK ыыы. Где. Приведен. Пример. Времени. Выполнения. Первого. И. Второго. DK Запроса. :-D Оригинальной БД, с которой возник вопрос у меня нет(да, я тренирую телепатор :), потому привожу данные с той, что генерил для тестов. Фулл фетч в Эксперте по нескольку раз, без отсоединения и перезапуска сервера: BIG_TABLE - 180 SMALL_TABLE - 1800 select s.id_small from small_table s join big_table b on b.id_small=s.id_small PLAN JOIN (S NATURAL, B INDEX (BIG_TABLE_IDX1)) Prepare : 16,00 ms Execute : 11 953,00 ms Avg fetch time: 0,01 ms Memory Current: 17 484 024 Max: 17 763 692 Buffers: 2 048 Operations Read : 16 802 Writes : 0 Fetches: 3 707 155 select s.id_small from small_table s join big_table b on b.id_small+0=s.id_small PLAN JOIN (B NATURAL, S INDEX (SMALL_TABLE_IDX1)) Query Time Prepare : 0,00 ms Execute : 30 640,00 ms Avg fetch time: 0,02 ms Memory Current: 17 460 580 Max: 17 763 692 Buffers: 2 048 Operations Read : 14 311 Writes : 0 Fetches: 12 723 070 -- -=Пописай в сугроб, почувствуй себя лазером!!!=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Fri, 12 Sep 2008 16:15:39 +0400: Попытался повторить это на тестовой БД - с трудом, но вроде получилось. http://rapidshare.com/files/144380650/TEST.rar.html 30МБ DY В общем, фикс у меня есть. На днях его оттестирую и (надеюсь) DY закоммичу. Если к понедельнику снапшоты оживут, то можно будет DY проверить на оригинальной не твоей базе :-) Ого, спасибо, проверим :) Это будет только в 2.5 или в 2.1.? тоже может попасть? -- -=Сумма длины ног и длины юбки - примерно одинакова для всех женщин=- With best regards, Nikolay Ponomarenko
������ �� ��������� ������������ � 1.5 �� 2.1
Hello, All! Коллеги переводят большую БД с 1.5 на 2.1, и часть запросов стала выполняться много медленнее. В частном случае, поменялся порядок таблиц - натуралом сервер стал идти по самой большой. Подробные данные ниже. Из изменений, который могли повлиять я увидел только посегментную статистику. И походже оптимизатору не на что опереться, для принятия оптимального решения. Ну а кол-во строк в таблице он не оценивает, та ведь? Собсно вопрос - предположения правильны и выхода как кроме +0(вроде как там запросов у них много) нет? TABLE_BIG = 2млн (PSG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PG) select SUM(PG.DEBIT), COUNT(DISTINCT SA.ORGANIZATION_ID) from TABLE_SMALL SA join TABLE_BIG PG on pg.organization_id = sa.organization_id join TABLE_MEDIUM PSG on psg.id = pg.drugs_id where sa.cluster_id = :v_cluster_id and sa.type_org_id = :v_type_org_id FB 1.5 plan join (sa natural, pg index (table_big_idx1), psg index (pk_table_medium)) FB 2.1.1 (с последней одс, после рестора) plan join (psg natural, pg index (table_big_idx3), sa index (table_small_org_idx)) create index table_small_org_idx on table_small (organization_id); (0,000577) alter table table_medium add constraint pk_table_medium primary key (id); (0,49) create index table_big_idx1 on table_big (organization_id, drugs_id); (0,004) селективность первого сегмента хуже TABLE_BIG_IDX1 = 0,000502260169 create index table_big_idx3 on table_big (drugs_id, type_org_id, city_id); (0,0111) селективность первого сегмента TABLE_BIG_IDX3 = 0,373343282 -- -=Убежать от взрывной волны можно. Просто надо выбегать заранее.=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
select SUM(PG.DEBIT), COUNT(DISTINCT SA.ORGANIZATION_ID) from TABLE_SMALL SA join TABLE_BIG PG on pg.organization_id = sa.organization_id join TABLE_MEDIUM PSG on psg.id = pg.drugs_id where sa.cluster_id = :v_cluster_id and sa.type_org_id = :v_type_org_id join and where мешать не нужно. У тебя сперва все соединится, а потом условие. Дмитрий
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Thu, 11 Sep 2008 13:01:37 +0300: join TABLE_MEDIUM PSG on psg.id = pg.drugs_id where sa.cluster_id = :v_cluster_id and sa.type_org_id = :v_type_org_id DL join and where мешать не нужно. У тебя сперва все соединится, а потом DL условие. А разве они не уйдут внутрь? -- -=Одна голова - хоpошо, а с тyловищем лyчше=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Thu, 11 Sep 2008 14:32:34 +0400: Сорри, опечатался. TABLE_BIG = 2млн (PG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PSG) FB 1.5 plan join (sa natural, pg index (table_big_idx1), psg index (pk_table_medium)) FB 2.1.1 (с последней одс, после рестора) plan join (psg natural, pg index (table_big_idx3), sa index (table_small_org_idx)) -- -=Мир житейский - это часы, гири которых - деньги, а маятник - женщины (с) Г.Э. Лессинг=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
А разве они не уйдут внутрь? Поменяй условие и посмотри как будет. Дмитрий
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Thu, 11 Sep 2008 15:11:23 +0400: TABLE_BIG = 2млн (PG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PSG) DY Я бы хотел взглянуть на эту базу. DY Ибо 2.1 не должен был выбрать такой плохой план. Оригинальная бд не моя, и весит 30гиг... Попытался повторить это на тестовой БД - с трудом, но вроде получилось. http://rapidshare.com/files/144380650/TEST.rar.html 30МБ Тестил запросом select sum(pg.debit), count(distinct sa.id_small) from small_table sa join big_table pg on pg.id_small=sa.id_small join medium_table psg on psg.id_medium=pg.id_medium where sa.id_fk_1=:sdf BIG_TABLE - pg 1,8 млн записей SMALL_TABLE - sa 1,8 тыс MEDIUM_TABLE - psg 16 тыс PLAN JOIN (PSG NATURAL, PG INDEX (BIG_TABLE_IDX2), SA INDEX (SMALL_TABLE_IDX1)) Кстати, добиться такого плана получилось только после заполнения ( update small_table t set t.id_fk_1=567 ) поля в маленькой таблице, когда оно было пустое(null во всех записях) - то план выбрался PLAN JOIN (SA NATURAL, PG INDEX (BIG_TABLE_IDX1), PSG INDEX (PK_MEDIUM_TABLE)) CREATE TABLE BIG_TABLE ( ID_SMALL INTEGER NOT NULL, ID_MEDIUM INTEGER NOT NULL, DEBIT NUMERIC(5,2) NOT NULL, ID_FK_1INTEGER NOT NULL -- случайные данные ); CREATE TABLE MEDIUM_TABLE ( ID_MEDIUM INTEGER NOT NULL ); CREATE TABLE SMALL_TABLE ( ID_SMALL INTEGER NOT NULL, ID_FK_1 INTEGER NOT NULL -- случайные данные ); ALTER TABLE MEDIUM_TABLE ADD CONSTRAINT PK_MEDIUM_TABLE PRIMARY KEY (ID_MEDIUM); CREATE INDEX BIG_TABLE_IDX1 ON BIG_TABLE (ID_SMALL, ID_MEDIUM); CREATE INDEX BIG_TABLE_IDX2 ON BIG_TABLE (ID_MEDIUM, ID_FK_1); CREATE INDEX SMALL_TABLE_IDX1 ON SMALL_TABLE (ID_SMALL); -- -=Лечил тyт одного то желтyхи, недолечил - помеp он. а как вскpыли - оказалось, китаец..=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Thu, 11 Sep 2008 14:20:30 +0300: А разве они не уйдут внутрь? DL Поменяй условие и посмотри как будет. Поменял, ничего не изменилось. И все же хочется узнать точно, разве в запросах вида select * from table1 t1 join table2 t2 on t2.id=t1.id where t1.f1=15 условие where t1.f1=15 не вносится внутрь ДО выполнения джойна? Первоисточник гласит что все же вносится. После него я собсно и стал выносить лишнее в where, в целях удобочитаемости запросов. http://ibase.ru/devinfo/dataaccesspaths.htm . С целью уменьшения результирующей кардинальности выборки, проверка предикатов всегда ставится как можно ниже (глубже) в дерево выполнения запроса. ... В то время как для внутренних и полных внешних соединений входные потоки независимы и могут читаться в произвольном порядке, ... Если вспомнить пункт 2.1, где описан принцип максимально глубокого помещения предикативных фильтров оптимизатором, то становится понятен один момент: индивидуальные табличные фильтры уйдут ниже методов соединения. Соответственно, в случае предиката вида (WHERE MASTER.F = 0) и отсутствии в таблице MASTER записей с полем F, равным нулю, обращений к внутреннему потоку соединения вообще не будет, так как в данном случае нет итерации по внешнему потоку (в нем нет записей). -- -=Деньги то начинают кончаться,то кончают начинаться=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitri! You wrote on Thu, 11 Sep 2008 17:36:17 +0400: DK вообще по идее идти натуралом по самой большой и жирной таблице - DK оптимальнее всего, если на нее ссылаются индексы с плохой DK селективностью. Вот тут даж не знаю - буквально час назад об этом задумались. Допустим есть две таблицы, одна на 1000 записей, и деталь к ней, на 10 тыс, равномерно заполненных. Простой джойн. Или тысяча обращений к большой таблице, или 100 тысч к маленькой? На простом искуственном тесте второй вариант получился в два раза медленнеей, если я чего не упустил :-/ DK кстати, где расклад по времени, что такая выборка тормознее? Тормознее, т.к. маленькая таблица, когда была основной, очень урезала выборку. Но относится ли этот случай к тем, которые должен разрулить оптмизатор в нынешнем виде - хз. -- -=Hенавижу вегетаpианцев! (с) Чипполино=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
Hello, Dmitry! You wrote on Thu, 11 Sep 2008 17:55:16 +0400: Оригинальная бд не моя, и весит 30гиг... DY Архив бекапа небось пару гиг всего :-) База не моя, потому все что смог - жалкие 30МБ нагенеренных экспертом :) Попытался повторить это на тестовой БД - с трудом, но вроде получилось. http://rapidshare.com/files/144380650/TEST.rar.html 30МБ DY ОК, посмотрю сегодня. Только я вот чесс гря не понимаю, на что может опираться оптимизатор, выбирая иной план. Ну разве что на размер таблицы? Ведь если судить по качеству индексов, то он берет, в принципе, оптимальный вариант. И в полуторке оно работало неверно, используя только информацияю о хорошей селективности композита? -- -=Люди, которые думают, что они знают все на свете, раздражают нас, людей, которые действительно все на свете знают.=- With best regards, Nikolay Ponomarenko
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
join and where мешать не нужно. imho изначально совет звучал как явные и неявные джойны мешать ненадо. я тут неявных в упор не вижу. а вот c +0 я бы поигрался.
Re: Переход с 1.5 - 2.1 реально?
А ещё 2.1 иначе сравнивает строки с числами.
Re: Переход с 1.5 - 2.1 реально?
On 22 июл, 12:39, Yurij [EMAIL PROTECTED] wrote: On Jul 22, 11:25 am, freemanzav [EMAIL PROTECTED] wrote: On 22 июл, 12:17, Kovalenko Dmitry [EMAIL PROTECTED] wrote: А ещё 2.1 иначе сравнивает строки с числами. А поточнее? http://sql.ru/forum/actualthread.aspx?bid=2tid=500904hl= А все беды от того, что в SQL вместо строгой типизации используется приведение типов :) Ну и вообще запросы там злые описаны, числа со строками сравнивать нехорошо. Опять рассуждения, что такое хорошо и что такое плохо. Как скучно :-(
Переход с 1.5 - 2.1 реально?
Привет всем.
Возникла задача портирования БД с 1.5 на 2.1 и тут же проявиласть
проблема:
при выполнении скрипта преобразования метадаты
select * from rdb$fix_metadata('WIN1251');
вываливается ошибка
invalid request BLR at offset 2581. as approximate floating-point
values in SQL dialect 1, but as 64-bit.
хотя сама БД создана и работает в 3-м диалекте.
Добавление SET SQL DIALECT 3; не помогает.
При этом бэкап поднялся без проблем.
Сервер 2.1.1 (Firebird-2.1.1.17910 Release)
Кто что подскажет?
Re: Переход с 1.5 - 2.1 реально?
plasmorf ...
Привет всем.
Возникла задача портирования БД с 1.5 на 2.1 и тут же проявиласть
проблема:
при выполнении скрипта преобразования метадаты
select * from rdb$fix_metadata('WIN1251');
вываливается ошибка
invalid request BLR at offset 2581. as approximate floating-point
values in SQL dialect 1, but as 64-bit.
хотя сама БД создана и работает в 3-м диалекте.
Добавление SET SQL DIALECT 3; не помогает.
Куда добавлял ?
При этом бэкап поднялся без проблем.
Он не проверяет BLR
В крайнем случае - создай скрипт со всеми метаданными, кроме таблиц.
Убей метаданные в копии БД. Эту копию апгрейди до ODS 11.1. Накати на
ней скрипт с метаданными.
--
Хорсун Влад
Re: Переход с 1.5 - 2.1 реально?
Возникла задача портирования БД с 1.5 на 2.1 и тут же проявиласть
проблема:
при выполнении скрипта преобразования метадаты
select * from rdb$fix_metadata('WIN1251');
вываливается ошибка
invalid request BLR at offset 2581. as approximate floating-point
values in SQL dialect 1, but as 64-bit.
хотя сама БД создана и работает в 3-м диалекте.
Судя по всему у вас не корректные с точки зрения 2ки метаданные.
Я бы посоветовал, перегнать сначало на 2.0.4.
Потом, перекомпилить все процедуры - исправляя несовместимости.
Ну а после исправления уже переводить на 2.1
Да, rdb$fix_metadata вроде должна писать на каком объекте обламалась...
--
Александр Замараев
