http://www.firebirdsql.org/download/snapshot_builds/win/
Сабжевая вещь опять сломалась :( Надолго? Заранее спасибо.
Re: http://www.firebirdsql.org/download/snapshot_builds/win/
Alexey Voytsehovich wrote: Сабжевая вещь опять сломалась :( Надолго? Команда починить уже дана. Ждем-с. -- Дмитрий Еманов
Re: backup restore
у меня есть подозрение, что там толпа индексов на этой маленькой табличке. 3. она занимает 90% размера и практически 100% обращений идет к ней. и еще один вопрос: если я правильно понял система которую вы разрабатывает 24х7 т.е. нет перерыва на ночь, когда можно было бы выполнять обслуживающие операции??
������ �� ��������� ������������ � 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
Nikolay Ponomarenko wrote: В частном случае, поменялся порядок таблиц - натуралом сервер стал идти по самой большой. Статистика по индексам свежая? Из изменений, который могли повлиять я увидел только посегментную статистику. Начиная с 2.0 оптимизатор вообще наполовину переделан. Ну а кол-во строк в таблице он не оценивает, та ведь? Оценивает. TABLE_BIG = 2млн (PSG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PG) 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)) Аналогично. -- Дмитрий Еманов
Re: backup restore
Качановский Дмитрий wrote: у меня есть подозрение, что там толпа индексов на этой маленькой табличке. 3. она занимает 90% размера и практически 100% обращений идет к ней. и еще один вопрос: если я правильно понял система которую вы разрабатывает 24х7 т.е. нет перерыва на ночь, когда можно было бы выполнять обслуживающие операции?? да - система круглосуточная. на данный момент приняли решение реализовывать такой вариант 1. в течение недели накапливаем данные, и удаляем, но мусор не собираем. 2. в субботу ночью сервер начинает накапливать данные в памяти (реализовано), доступ к бд прекращается (насчет этого еще не все ясно, будем экспериментировать) 3. запускается бакуп 4. проверяем чтобы не было ошибок 5. запускаем рестор 6. переименовываем старую в отресторенную 7. сервер сбрасывает накопленные данные в бд ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд.
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
Nikolay Ponomarenko wrote: Сорри, опечатался. TABLE_BIG = 2млн (PG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PSG) Я бы хотел взглянуть на эту базу. Ибо 2.1 не должен был выбрать такой плохой план. -- Дмитрий Еманов
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
А разве они не уйдут внутрь? Поменяй условие и посмотри как будет. Дмитрий
Re: off: к пятнице
Опять про БАК. http://rutube.ru/tracks/999820.html?v=86524c2ef35fa87cbe95073877f5f1c8
Re[2]: backup restore
Hello Alexey, Thursday, September 11, 2008, 2:35:23 PM, you wrote: AV да - система круглосуточная. на данный момент приняли решение реализовывать AV такой вариант AV 1. в течение недели накапливаем данные, и удаляем, но мусор не собираем. AV 2. в субботу ночью сервер начинает накапливать данные в памяти (реализовано), AV доступ к бд прекращается (насчет этого еще не все ясно, будем экспериментировать) AV 3. запускается бакуп AV 4. проверяем чтобы не было ошибок AV 5. запускаем рестор AV 6. переименовываем старую в отресторенную AV 7. сервер сбрасывает накопленные данные в бд AV ЗюЫю AV рук-во поставило в план задач тестирование необходимого нам функционала AV (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих AV видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям AV (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о AV смене субд. А если без удалений совсем Считай всего то 400 гектар в год. На новый год заводите новую базу и пересекаете ее на неделю со старым годом. Тема Дня: Тот, кто хpапит, всегда засыпает пеpвым. До не скорой встречи в аду, Maxmailto:[EMAIL PROTECTED]
Re: backup restore
âèäàõ ñóáä - ìññêë, ïîñòãðå, îðàêë. Åñëè îäíà èç íèõ óäîâëåòâîðèò òðåáîâàíèÿì îòïèøè ñþäà î ðåçóëüòàòàõ. èíòåðåñíî
Re: backup restore
Доброго времени суток! On 11 сент, 14:35, Alexey Voytsehovich wrote: ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд. Вероятно, что на блокировочнике Вам будет полегче. По поводу существующей системы на FB - я бы попробовал хранить данные за каждый день в отдельных таблицах. В этом случае чистка данных - это просто удаление таблицы без негативных последствий в виде сборки мусора. Правда, усложняются все запросы, но это решаемо через ES/EB. -- С уважением, Евгений
Косяк или Фича ?
Привет, Всем! Ситуация: 1) Ставим Firebird 2.1 на машину с именем USER1 и заруливаем его на порт 3051 2) Ставим на сервер c именем SERV Firebird 2.0, который по умолчанию работает на порту 3050 3) С USER1 запускаем клиент-приложение с строкой подключения: localhost/3051:C:\local_base.fdb - подключение проходит успешно 4) Меняем в клиент-приложении строку подключения на: SERV:C:\serv_base.fdb - ОШИБКА ПРИ ПОДКЛЮЧЕНИИ! С помощью программы TCPVIEW смотрим куда же пытается подключится клиент-приложение ? Оказывается что на SERV:3051 ! А там собственно на этом порту ничего нет :) И только после исправления строки подключения на: SERV/3050:C:\serv_base.fdb - Клиент-приложение подключилось нормально Вопросы: Где запоминается порт последнего удачного подключения ? И должно ли так на самом деле работать ? With best regards, Oleg Prosvetov.
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Hello, Nikolay! Nikolay Ponomarenko wrote: Ну а кол-во строк в таблице он не оценивает, та ведь? оценивает. по размеру записи в rdb$formats и по количеству pointer page. т.е. количество записей в данном случае это вообще все версии, плюс фрагментированные страницы, и т.д. Собсно вопрос - предположения правильны и выхода как кроме +0(вроде как там запросов у них много) нет? вообще по идее идти натуралом по самой большой и жирной таблице - оптимальнее всего, если на нее ссылаются индексы с плохой селективностью. кстати, где расклад по времени, что такая выборка тормознее? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
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: Косяк или Фича ?
Oleg Prosvetov wrote: 1) Ставим Firebird 2.1 на машину с именем USER1 и заруливаем его на порт 3051 2) Ставим на сервер c именем SERV Firebird 2.0, который по умолчанию работает на порту 3050 3) С USER1 запускаем клиент-приложение с строкой подключения: localhost/3051:C:\local_base.fdb - подключение проходит успешно 4) Меняем в клиент-приложении строку подключения на: SERV:C:\serv_base.fdb - ОШИБКА ПРИ ПОДКЛЮЧЕНИИ! С помощью программы TCPVIEW смотрим куда же пытается подключится клиент-приложение ? Оказывается что на SERV:3051 ! Ибо fbclient через реестр нашел firebird.conf сервера, прочитал оттуда RemoteServicePort и через него полез. Сделай instreg remove на USER1 и все заработает. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Оригинальная бд не моя, и весит 30гиг... Архив бекапа небось пару гиг всего :-) Попытался повторить это на тестовой БД - с трудом, но вроде получилось. http://rapidshare.com/files/144380650/TEST.rar.html 30МБ ОК, посмотрю сегодня. -- Дмитрий Еманов
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: Косяк или Фича ?
Hello, Dmitry! You wrote on Thu, 11 Sep 2008 17:53:01 +0400: DY Ибо fbclient через реестр нашел firebird.conf сервера, прочитал оттуда DY RemoteServicePort и через него полез. Как то это неправильно. Выходит чтобы испортить людям жизнь достаточно установить Firebird и зарулить его на порт 3051 и все программы которые работали до этого с каким нибудь сервером перестают работать ? DY Сделай instreg remove на USER1 и все заработает. Это полумера With best regards, Oleg Prosvetov. E-mail: [EMAIL PROTECTED]
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: Косяк или Фича ?
Hello, Vlad! You wrote on Thu, 11 Sep 2008 16:55:42 +0300: VK Клиент VK смотрит VK в firebird.conf А может не стоит смешивать настройки клиента и сервера ? With best regards, Oleg Prosvetov. E-mail: [EMAIL PROTECTED]
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
Временные права
Доброго времени суток! Недавно перешёл на Firebird 2.5.0.20842 SuperClassic, и появилась странная бага - права, которые я раздаю за период использования этой версии, работают только до перезагрузки сервера(останавливаю службу, жду завершения всех коннектов, запускаю заново). При попытке доступа к объектам(таблицам, процедурам и т.п.), созданным в этой версии сервера, получаю ошибку, мол прав нет на доступ, смотрю в IBEpert'e(2008.08.31), права есть - кружок стоит зеленый, убираю их, выставляю заново - всё работает, но до перезагрузки сервера... Смотрел в rdb$user_priveleges, права выставлены, но пока их не снимешь-снова раздашь, доступа нет... С правами, розданными в прежних версиях, таких проблем нет... Таки писать в трекер? З.ы. чтот в последнее время nightly build'ов не наблюдается новых, надолго? Аль готовится альфа 2.5 к релизу?
Re: Косяк или Фича ?
Hello, Oleg! Oleg Prosvetov wrote: Как то это неправильно. Выходит чтобы испортить людям жизнь достаточно установить Firebird и зарулить его на порт 3051 и все программы которые работали до этого с каким нибудь сервером перестают работать ? если я правильно помню, то я матюкался на это. чего клиенту в конфиге надо - не помню. тут проблема в том, что запись в реестре о местоположении клиента и сервера одна. Раньше клиенту эта запись в реестре нужна была чтобы знать где искать msg. А сейчас... -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Косяк или Фича ?
Oleg Prosvetov ... Hello, Vlad! You wrote on Thu, 11 Sep 2008 16:55:42 +0300: VK Клиент VK смотрит VK в firebird.conf А может не стоит смешивать настройки клиента и сервера ? А может тебе напомнить, когда 1.5 выпустили ? -- Хорсун Влад PS в вулкане у клиента отдельный конфиг. Переедет ли это в 3.0, не скажу
Re: Временные права
Hello, Oleg! Олег Короткий wrote: Недавно перешёл на Firebird 2.5.0.20842 SuperClassic, и появилась FB 2.5 - альфа-версия. странная бага - права, которые я раздаю за период использования этой версии, работают только до перезагрузки сервера(останавливаю службу, жду завершения всех коннектов, запускаю заново). При попытке доступа к объектам(таблицам, процедурам и т.п.), созданным в этой версии сервера, получаю ошибку, мол прав нет на доступ, смотрю в IBEpert'e(2008.08.31), права есть - кружок стоит зеленый, убираю их, выставляю заново - всё работает, но до перезагрузки сервера... Смотрел круто. в rdb$user_priveleges, права выставлены, но пока их не снимешь-снова раздашь, доступа нет... С правами, розданными в прежних версиях, таких проблем нет... Таки писать в трекер? так и пиши. на выбор а) я не знаю оператор GRANT б)Кнопка зеленая, а потом нифига. если серьезно, то сначала проверь сохраняются ли права выданные через оператор GRANT, и если да - иди матюкать Хвастунова. Если нет, то будет test case. Только уже без зеленых кнопочек. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Hello, Nikolay! Nikolay Ponomarenko wrote: DK кстати, где расклад по времени, что такая выборка тормознее? Тормознее, т.к. маленькая таблица, когда была основной, очень урезала выборку. Но относится ли этот случай к тем, которые должен разрулить оптмизатор в нынешнем виде - хз. ыыы. Где. Приведен. Пример. Времени. Выполнения. Первого. И. Второго. Запроса. ? :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: И все же хочется узнать точно, разве в запросах вида select * from table1 t1 join table2 t2 on t2.id=t1.id where t1.f1=15 условие where t1.f1=15 не вносится внутрь ДО выполнения джойна? Вносится. Первоисточник гласит что все же вносится. После него я собсно и стал выносить лишнее в where, в целях удобочитаемости запросов. И правильно делаешь. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Тормознее, т.к. маленькая таблица, когда была основной, очень урезала выборку. Но относится ли этот случай к тем, которые должен разрулить оптмизатор в нынешнем виде - хз. Не относится, увы. -- Дмитрий Еманов
Re: backup restore
Oleg Matveyev wrote: видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям отпиши сюда о результатах. интересно ок
Re: backup restore
Кузнецов Евгений wrote: Доброго времени суток! On 11 сент, 14:35, Alexey Voytsehovich wrote: ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд. Вероятно, что на блокировочнике Вам будет полегче. По поводу существующей системы на FB - я бы попробовал хранить данные за каждый день в отдельных таблицах. В этом случае чистка данных - это просто удаление таблицы без негативных последствий в виде сборки мусора. но не устраняет проблем с фрагментацией исходного бд файла. Правда, усложняются все запросы, но это решаемо через ES/EB. обычная хранимка имхо :)
Re: backup restore
Dmitry Voroshin wrote: Alexey Voytsehovich ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене суб А почему нет MySQL? Нетранзакционный движек дролжен на такой задаче показать наибольшую скорость. может посмотрим и на него. но с ним не все понятно в лицензионной политике к сожалению.
Re: backup restore
Храпко Виктор wrote: Alexey Voytsehovich[EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд. Вообще такая бяка реализуется на ОРАКЛЕ. Поставь оракл и прочитай Тома Кайта Книжку. Там написано Как создавать сегментированную таблицу и по мере необходимости просто добавлять и удалять сегменты таблицу. Удаление сегмента это секунды вооот за это спасибо. почитаю про сегментирование. Есть ли такое (или аналог в mssql)?
Re: backup restore
в mssql тоже есть сегментирование таблиц
Re: ������ �� ��������� ������������ � 1.5 �� 2.1
join and where мешать не нужно. imho изначально совет звучал как явные и неявные джойны мешать ненадо. я тут неявных в упор не вижу. а вот c +0 я бы поигрался.
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Только я вот чесс гря не понимаю, на что может опираться оптимизатор, выбирая иной план. Ну разве что на размер таблицы? Размер считается в обоих версиях приблизительно одинаково. В данном случае разница лишь в посегментном учете селективности. Ведь если судить по качеству индексов, то он берет, в принципе, оптимальный вариант. И в полуторке оно работало неверно, используя только информацияю о хорошей селективности композита? Именно так. И на (в принципе худший) вариант наложилось наличие фильтра по малой таблице, который наверняка и дал ускорение. Надо бы какую-то эвристику ввести для неиндексированных предикатов, тогда результат мог бы быть более предсказуемым. Она как бы есть, но сильно зачаточная :-) Подумаю над этим. -- Дмитрий Еманов
Re: Косяк или Фича ?
Доброго времени суток! To Dmitry Yemanov Кстати, а как поживает упрощение, которое нам не понравится ( http://www.sql.ru/forum/actualthread.aspx?tid=529311#5332070 ), и в чем оно будет заключаться? -- С уважением, Евгений
Re: Временные права
FB 2.5 - альфа-версия. Таки в курсе... а) я не знаю оператор GRANT б)Кнопка зеленая, а потом нифига. Оператор GRANT я знаю, не первый год с firebird'ом работаю, если б не знал, так бы и спросил, где бага, в FB или IBE. С GRANT'ом косяк тот же. Просто в IBE проще и быстрей права раздавать. Ладно, отпишусь в трекер. -- Dmitri Kouzmenko,www.ibase.ru, (495) 953-13-34
автоматическое обслуживание
Пишу тут план обслуживания. правильно ли все понимаю. 1. переводим базу в режим SINGLE шутдауна - gfix -shut single -f 60 (это значит что только одно подключение админа сможет войти?) 2. делаем бакуп gbak -b -g 3. проверяем %ERROR_LEVEL% была ли ошибка 4. делаем ресторе в другой алиас gbak -c 5. проверяем %ERROR_LEVEL% была ли ошибка 6. если ни на одном шаге не было ошибок, архивируем старую базу и переименовываем под её алиас свежесозданную базу 7. на этом шаге уже могут быть подключения клиентов? или надо перевести в онлайн отресторенную базу? и что будет если в момент переименования клиент стукнется к бд? заранее спасибо за комментарии :)
Re: Косяк или Фича ?
Кузнецов Евгений wrote: Кстати, а как поживает упрощение, которое нам не понравится ( http://www.sql.ru/forum/actualthread.aspx?tid=529311#5332070 ), и в чем оно будет заключаться? Жди 3.0, узнаешь. -- Дмитрий Еманов
Re: [asterisk-users] Asterisk and Fedora 9
Pascal Bruno [EMAIL PROTECTED] wrote: I am about to install Asterisk on a Fedora 9 box, but i see with yum, they only have Asterisk 1.6 beta in the package repos which I didn't really want to install until they have a stable release. Does anybody know or have a good and easy way to install Asterisk 1.4 on fedora 9? Thank you. you could either grab it from the fedora 8 repo, or from atrpms.net. -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
http://www.geckoandfly.com Get! YahooAutoMailer $9.95 - Auto-Post to Unlimited Yahoo Groups
Automatic Posting to Google Groups.Did you know Yahoo Groups is THE MOSTnbsp; USED INTERNET GROUP Today!nbsp;How About MSN GROUPS and GOOGLE GROUPS?nbsp; nbsp;These are the BIG 3 Of Group Advertising. http://www.forex-futures-trading.info/mailer.html --~--~-~--~~~---~--~~ Working life is a bed of roses with the thorns of course, there are plenty of ways to make money online, a fine example is blogging, something everyone is familiar with. If you happen to stumble upon this forum by chance, you're pretty much on your way to financial freedom. Visit the official group or website for more information at http://groups.google.com/group/make-money-online?hl=en and http://www.geckoandfly.com/make-money-online/ -~--~~~~--~~--~--~---
Free Registration/Earn $1.25 Per Referral!
Get $6 on your Welcome Survey. It's absolutely FREE To join. Complete the surveys you get paid. Get paid $1 to $25 per Survey/Panel group. Refer and earn extra $1.25 per referral! http://www.urlfreeze.com/rjm42/Surveys/ -- I Know How To Make Money On The Net www.urlfreeze.com/rjm42/Free/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups onlineassociates group. To post to this group, send email to onlineassociates@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/onlineassociates -~--~~~~--~~--~--~---
