Re: ÷ÙÞÉÓÌÅÎÉÅ ÓÅÌÅËÔÉ×ÎÏÓÔÉ ÉÎÄÅËÓÁ ÄÌÑ BETWEEN, LESS, GREAT É STARTING

[Alexander A. Venikov]

Hello, Yuri!
You wrote to All on Tue, 27 Jun 2006 09:24:54 +0300:

 YG> ? Так, как она вычисляется сейчас получается, что любой индекс
 YG> фактически не будет использоваться... Нет ли здесь ошибки? Именно
 YG> так и задумывалось?
Вроде Влад всё объяснил. Если  мы имеем запрос с > или < (>=, <=), В СРЕДНЕМ, 
независимо от наличия/отсутствия индекса мы выбираем половину таблицы. 
Отсюда - 0.5. BETWEEN - комбинация из >= и <=. То есть, опять же, В СРЕДНЕМ, 
between выбирает четверть таблицы. Естественно, "зависит от"... (от реальных 
значений параметров). Но на этапе prepare значения параметров неизвестны, 
оптимизатор об этих значениях ничего не знает. Отсюда и числа - 0.5 и 0.2 
(немножко меньше, чем 0.25).

Удач
--
Alexander A. Venikov, Tobolsk, Russia
Real e-mail address is venixtntobru 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ������������ �����

[Dmitri Kuzmenko]

Hello, Alexander!

Alexander Goldun wrote:

> A good plan, not necessarily the best plan

Да ладно, с этим все ясно. План хороший, плохой, злой... :-)

Ты лучше скажи, как там у вас с пересчетом селективности
индексов - когда она делается?

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Вычисление селективности индекса для BETWEEN, LESS, GREAT и STARTING

[Yuri Grabar]

Hello, All!

Возвращаясь к пройденной теме...
Итак, файл Optimize.cpp со строки 1584:

// Adjust the compound selectivity using the reduce factor.
// It should be better than the previous segment but worse
// than a full match.
const double diffSelectivity = scratch[i]->selectivity - selectivity;
selectivity += (diffSelectivity * factor);
fb_assert(selectivity <= scratch[i]->selectivity);
scratch[i]->selectivity = selectivity;

scratch[i]->selectivity  - начальная селективность для оценки (равна 
MAX_SELECTIVITY, т.е. 1.0)
selectivity- селективность текущего индекса
factor- фактор уменьшения влияния селективности для between = 0.2

Вычисление результирующей селективности происходит немного станно...  При 
изменении исходной селективности индекса от 0 до 1 вычисленная 
результирующая селективность изменяется от 0.2 до 1.0. Не должна ли 
результирующая селективность вычисляться хотя бы:

scratch[i]->selectivity = selectivity + selectivity * factor;

? Так, как она вычисляется сейчас получается, что любой индекс фактически не 
будет использоваться... Нет ли здесь ошибки? Именно так и задумывалось?

-- 
With best regards, Yuri Grabar. 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Off: Creation file timestamp

[Alexander A. Venikov]

Hello, Slava!
You wrote  on Mon, 26 Jun 2006 11:46:45 +0400:

 AAV>> Простите, но что-то никгде не нарыл в хелпе и в Инете. Как можно
 AAV>> изменить дату/время создания файла? D7. Файловая система - NTFS.

 SE> Win32.SetFileTime.
Спасибо, помогло. Блин, грабли. Функция DateTimeToFileDate - целая,  изменение 
даты/времени на 2 секунды изменяет результат на 1. То есть, если мне нужно 
установить время создания/модификации файла 00:00:01 - это время не годится. 
Вот и пришлось опять же в SetFileTime подкручивать (там в 100-наносекундных 
интервалах).

Ладно, офтопик, завязываю.  Спасибо еще раз.

Удач
--
Alexander A. Venikov, Tobolsk, Russia
Real e-mail address is venixtntobru 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re[2]: Сверхбольшие таблиы

[Yuris W. Auzinsh]

Здравствуйте, Alexander Goldun.

Недавно (26 июня 2006 г., 16:57:08) Вы писали:

AG> Вторыми :)
А кто первый?

-- 
  Удачи...
   
   Yuris W. Auzinsh aka Zuz,
   ICQ UIN: 5 8 2 5 6 3 7 4,
   e-mail : zuz(аt)mail.ru



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander V. Skvortsov]

"Horsun Vlad" сообщил/сообщила в новостях следующее:

>> > HV> Спасибо,  но - где тут про автоматическую корреляцию плана запроса
>> > HV> с параметрами в зависимости от их значенией в рантайме ?
>> > Значит Вы будите первыми! ;-)
>Мы спим первыми, а вы нас будите всё время :)
>> Вторыми :)
>Ссылка ?
http://www.citforum.ru/database/articles/leo.shtml

> Хорсун Влад


Sincerely yours
Alexander V. Skvortsov 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Vlad Horsun]

"Alexander Goldun" ...
> Vlad Horsun пишет:
>
> > Да, да. Когда такое читаю, думаю - иногда лучше молчать, если сказать 
> > нечего.
> > Хороший пример документации ASA :)
>
> А что ты ожидал там увидеть?

Документацию. а не

> Это же общие фразы,

Мы всё-таки не в маркетинг играем. Не я по крайней мере.

> basic concepts так
> сказать. Большего и не нужно для решения большинства задач и достаточно,
> что бы в общих чертах получить представление, не будучи специалистом по
> разработке серверов БД :) Ты ж не ожидаешь, что в инструкции по
> эксплуатации современного авто будут математические выкладки из
> сопромата и термодинамики? Взгляд у тебя немножко предвзятый.

Аналогия неверная, как и большинство аналогий.

> >> Уж при дисконнекте клиента точно выкинет
> > Конечно - кеш-то только в рамках коннекта живёт :-D
>
> Могу сделать вывод, глядя на работу реальных систем, что тоже вполне
> логично. Разные коннекты - разные юзеры и, возможно, разные потребности
> в выборках данных.

Ага. Сколько коннектов, столько и совершено разных приложений с абсолютно
разными запросами. Угу. Логично.

Взгляд у тебя предвзятый (с) Всё, что в ASA - это хорошо и вполне логично 
(с)

Кеш планов на коннект - это ещё один маразм, косвенно показывающий, что не
всё у ASA с этим ладно. Может потому и запросы каждый раз перекомпилируются ?
:-D

Всё, всё. Надоело. Тут не форум по о[б]суждению ASA :)

--
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Vlad Horsun]

"Alexander Goldun" ...
> Vlad Horsun пишет:
>
> >> А что есть идеал по твоему? Не вообще, а по данному вопросу. Все равно
> >> ведь компромисс искать надо между затратами на оптимизацию и эффектом от
> >> этой самой оптимизации
> >
> > Идеал - идеальный план для любых значений пар-ров :-D
>
> Который недостижим, как и большинство прочих идеалов.

Мда. Банальности, оказывается, есть не только в доке по ASA :)

> > ASA ведёт себя не предсказуемо - план запросов в процедурах может быть 
> > далёк
> > от оптимального. Да, те же запросы, выполненные отдельно, имеют шансы быть
> > лучше оптимизированными (за счёт постоянного перевычисления плана), но в 
> > моей
> > практике 95% запросов живёт таки в процедурах.
>
> В моей практике скорее наоборот.

Уж не потому ли, что процедурами пользоваться неудобно ? :-D

> P.S. Кстати, в случае некоторых примитивных селективных процедур вообще
> не мыслю, как можно без оптимизации при исполнении. Если процедура -
> просто селект с джойнами и условиями, то при выборке из нее план
> строится не только с учетом значений параметров, но и с учетов условий,
> накладываемых на выборку извне. Весьма удобно в разработке.

В доке очень подробно (на целых полэкрана) расписано, что планы запросов
в процедурах _кешируются_. Так штааа...

Давай, если у тебя нет аргументов, прекратим это словоблудие. Ты показал
подход ASA, а я убедился что это лично мне не нравится и имеет слабое отношение
к начальной проблеме. Так что я лично не буду думать в эту сторону в FB (да и не
собирался, если честно :) Отрицательный результат - тоже результат, аминь


--
Хорсун Влад

PS Украина - Швейцария 3:0, с чем всех и поздравляю !



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Vlad Horsun пишет:

>> А что есть идеал по твоему? Не вообще, а по данному вопросу. Все равно
>> ведь компромисс искать надо между затратами на оптимизацию и эффектом от
>> этой самой оптимизации
> 
> Идеал - идеальный план для любых значений пар-ров :-D

Который недостижим, как и большинство прочих идеалов.

> ASA ведёт себя не предсказуемо - план запросов в процедурах может быть 
> далёк
> от оптимального. Да, те же запросы, выполненные отдельно, имеют шансы быть
> лучше оптимизированными (за счёт постоянного перевычисления плана), но в моей
> практике 95% запросов живёт таки в процедурах.

В моей практике скорее наоборот.

P.S. Кстати, в случае некоторых примитивных селективных процедур вообще 
не мыслю, как можно без оптимизации при исполнении. Если процедура - 
просто селект с джойнами и условиями, то при выборке из нее план 
строится не только с учетом значений параметров, но и с учетов условий, 
накладываемых на выборку извне. Весьма удобно в разработке.


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Vlad Horsun пишет:

> Да, да. Когда такое читаю, думаю - иногда лучше молчать, если сказать 
> нечего.
> Хороший пример документации ASA :)

А что ты ожидал там увидеть? Это же общие фразы, basic concepts так 
сказать. Большего и не нужно для решения большинства задач и достаточно, 
что бы в общих чертах получить представление, не будучи специалистом по 
разработке серверов БД :) Ты ж не ожидаешь, что в инструкции по 
эксплуатации современного авто будут математические выкладки из 
сопромата и термодинамики? Взгляд у тебя немножко предвзятый.

>> Уж при дисконнекте клиента точно выкинет
> Конечно - кеш-то только в рамках коннекта живёт :-D

Могу сделать вывод, глядя на работу реальных систем, что тоже вполне 
логично. Разные коннекты - разные юзеры и, возможно, разные потребности 
в выборках данных.



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Vlad Horsun]

"Alexander Goldun" ...
> Vlad Horsun пишет:
>
> > Дык - план-то уже в кеше. И не факт, что самый хороший :-D
>
> Разумеется. По этому поводу я могу опять привести ссылку и цитату для
> детсада :)
> http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0390.htm
>
> A good plan, not necessarily the best plan
>
> The goal of the optimizer is to find a good access plan. Ideally, the
> optimizer would identify the most efficient access plan possible, but
> this goal is often impractical. Given a complicated query, a great
> number of possibilities may exist.

Да, да. Когда такое читаю, думаю - иногда лучше молчать, если сказать 
нечего.
Хороший пример документации ASA :)

> > И кто его знает, когда ASA решит его из кеша выкинуть
>
> Если разработчики признаются - расскажу.

Когда факт выполнения будет сильно отличаться от плана. Но это уже поздно, 
т.к.
плохое выполнение запроса уже произошло. Поэтому мне и не нравится (и непонятна)
идея накопления статистики выполнения, влияющая на планы. Т.е. сама идея вроде
бы правильная, но как начнёшь копать чуть глубже - не всё так гладко.

> Уж при дисконнекте клиента точно выкинет

Конечно - кеш-то только в рамках коннекта живёт :-D

http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm

The plan cache is a per-connection cache of the data structures used to execute 
an access plan

Оттуда же :

The maximum number of plans to cache is specified with the option setting 
MAX_PLANS_CACHED.
The default is 20

Можно сказать, что в ASA по-умолчанию отсутствует кеш планов :-D

--
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Vlad Horsun]

"Alexander Goldun" ...
> Horsun Vlad пишет:

> > Просто эта фича ASA
> > а) не совсем в тему того, о чём говорились,
>
> Это просто в тему использования значений параметров при оптимизации,
> просто к сведению, не для спора. Интересно или нет - вам решать.

Дык - а кто спорит ? :)

> > б) весьма далека от идеала (ладно - imho :)
>
> А что есть идеал по твоему? Не вообще, а по данному вопросу. Все равно
> ведь компромисс искать надо между затратами на оптимизацию и эффектом от
> этой самой оптимизации

Идеал - идеальный план для любых значений пар-ров :-D

ASA ведёт себя не предсказуемо - план запросов в процедурах может быть далёк
от оптимального. Да, те же запросы, выполненные отдельно, имеют шансы быть
лучше оптимизированными (за счёт постоянного перевычисления плана), но в моей
практике 95% запросов живёт таки в процедурах.

>   >> P.S. Гистограммы в FB планируются? В roadmap упоминается со средним
> >> приоритетом  Optimizer improvements ... more data statistics
> > Да, конечно
>
> В FB3?

Там увидим. Не в 2.1 точно

--
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Vlad Horsun пишет:

> Дык - план-то уже в кеше. И не факт, что самый хороший :-D

Разумеется. По этому поводу я могу опять привести ссылку и цитату для 
детсада :)
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0390.htm

A good plan, not necessarily the best plan

The goal of the optimizer is to find a good access plan. Ideally, the 
optimizer would identify the most efficient access plan possible, but 
this goal is often impractical. Given a complicated query, a great 
number of possibilities may exist.

> И кто его знает, когда ASA решит его из кеша выкинуть

Если разработчики признаются - расскажу. Уж при дисконнекте клиента 
точно выкинет


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Vlad Horsun]

"Alexander Goldun" ...
> Horsun Vlad пишет:
>
> >> Если стоимость такого плана
> >> близка к лучшей зафиксированной стоимости запроса, то план добавляется в
> >> кэш и используется в дальнейшем.
> >
> > Это работает только если пар-ры не плавают. Рассчитывать на
> > это - глупо (маразм :)
>
> Нет, все-таки возражу ;)

:)

> Как раз таки наоборот: если они сильно плавают, то скорее всего выгоднее
> будет каждый раз оптимизировать, чем тупо лепить один и тот же план со
> всеми возможными значениями параметров.

Дык - план-то уже в кеше. И не факт, что самый хороший :-D
И кто его знает, когда ASA решит его из кеша выкинуть

--
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Часто обновляемые записи

[Ded]

Korg wrote:

> Здравствуйте! У мня следующая ситуация: постоянно принимаю данные от
> оборудования (GPS-координаты то машин). Интервал 15-60 сек, порядка 100-200
> машин. Ложу данные в историю.

   Эт не про вас? Знакомый сказывал:

__
В вскр. позвонила мама и сказала, что от стоянки в Меге угнали ее новый 
Рав-4 со спутниковой сигналкой. Приехал, позвонил комунадо. В результате 
вся Ленинградка была перекрыта спецполком ДПС, в Химках и СЗАО был 
объявлен план "Перехват". Машину искали 12 экипажей ДПС и опера. 
Почему-то оператор этого сраного Автолокатора давал постоянно новые 
координаты и говорил, что машина в движении. Вся хохма заключалась в 
том, что ее никто не угонял, она спокойно стояла метрах в 20 от 
предполагаемого места угона между двумя Тахами. Млия, до часу ночи 
писали объяснительные и поили командиров экипажей конъяком...
Люди, пришедшие из Ашана к своей Тахе были в легком акуе, когда к ним с 
визгом примчалось 5 машин ДПС сразу и оттуда вылезла куча 
автоматчиков... Короче кино и немцы...
__

уж больно на кривое управление транзакциями смахивает :-D

-- 
Regards. Ded.


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Horsun Vlad пишет:

>> Если стоимость такого плана
>> близка к лучшей зафиксированной стоимости запроса, то план добавляется в
>> кэш и используется в дальнейшем.
> 
> Это работает только если пар-ры не плавают. Рассчитывать на
> это - глупо (маразм :)

Нет, все-таки возражу ;)

Как раз таки наоборот: если они сильно плавают, то скорее всего выгоднее 
будет каждый раз оптимизировать, чем тупо лепить один и тот же план со 
всеми возможными значениями параметров.


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Horsun Vlad пишет:

>> Про маразм - это сгоряча.
> Нет, не сгоряча. В ASA параметризированные запросы теряют
> половину своих преимуществ - отсутствие повторной оптимизации,
> которая может быть дольше, чем сам запрос

Может быть, а может и не быть. Оптимальное выполнение запроса - часто 
весьма значимое преимущество. Дискутировать по этому вопросу по существу 
не готов, но на время оптимизации жаловаться не приходилось. Даже 
настройкой глубины оптимизации ни разу не пользовался - дефолтное 
значение вполне устраивает.

>> IMHO маразм - это использование единого плана
>> для всех возможных значений параметров.
> Для запросов в процедурах так оно и есть (даже! :) в ASA

В том случае, если общий план не сильно дороже зависящего от параметров.

>> Упрощенный, но жизненный пример - отбор документов, скажем по периоду,
>> складу и статусу. Есть индекс по дате, FK по складу, индекс по статусу.
>> Дата более-менее равномерна, склады заметно отличаются объемом потока
>> документов, а распределение по статусу вообще супер перекошенное - 99%
>> закрыты и очень небольшое кол-во "в обработке". Какой индекс оптимальнее
>> будет?
> 
> Это вопрос или таки пример ? :-D

Это пример вопроса, ответ на который зависит от значений параметров :)

> http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm
> 
> Да, я уже это прочитал. Кстати - глубина доки по ASA
> поражает - такое впечатление, что они её пишут для детсадов
> и боятся (или просто не знают ?) написать что-нибудь более
> сложное, чем 2х2

Ну, что есть, то есть. По крайней мере есть возможность дать ссылку на 
нужную страницу доки. Все ж таки не open source. Что-то в принципе можно 
вытрясти из разработчиков на форуме, но потребности в этом не возникало.

>> Если стоимость такого плана
>> близка к лучшей зафиксированной стоимости запроса, то план добавляется в
>> кэш и используется в дальнейшем.
> 
> Это работает только если пар-ры не плавают. Рассчитывать на
> это - глупо (маразм :)

Вести полемику на эту тему не собираюсь, ибо тут не SQL.RU и я лишь 
пользователь сервера, а не разработчик.

> Просто эта фича ASA
> а) не совсем в тему того, о чём говорились,

Это просто в тему использования значений параметров при оптимизации, 
просто к сведению, не для спора. Интересно или нет - вам решать.

> б) весьма далека от идеала (ладно - imho :)

А что есть идеал по твоему? Не вообще, а по данному вопросу. Все равно 
ведь компромисс искать надо между затратами на оптимизацию и эффектом от 
этой самой оптимизации

  >> P.S. Гистограммы в FB планируются? В roadmap упоминается со средним
>> приоритетом  Optimizer improvements ... more data statistics
> Да, конечно

В FB3?


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ����� ����������� �����

[Dmitri Kuzmenko]

Hello, Korg!

Korg wrote:

> IBAnalyst ругается на то, что в этой таблице слишком много версий данных:
> 
> Taблицы c мнoжecтвoм вepcий
> LAST_CAR_POINT Зaпиceй: 15, вepcий: 3862, дл. вepcий 54% oт дл. зaпиceй
> 
> Вопрос: правильно ли я делаю, и как надо делать правильней?

причиной накопления версий является "неработа" сборки мусора.
в твоем случае причина скорее всего в длительности работы транзакций.
Сделай их короче, тогда версии будут становиться мусором, и будут
собираться автоматически.

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ������������ �����

[Dmitri Kuzmenko]

Hello, Alexander!

Alexander Goldun wrote:

>(И понятие "плохой индекс" мне тоже кажется достаточно маразматичным).

если приоритет никто не оспорит, то утвердил такую характеристику
я, в IBAnalyst. :-) Кстати, там же и расписал в хелпе, что имеется
в виду под "плохостью" такого индекса.
Разумеется, в отсутствии гистограмм для IB/FB такой индекс
действительно "плохой", т.к. имеет сильный перекос от среднего
распределения значений.

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Horsun Vlad]

"Alexander Goldun" ...
> Вторая попытка отправить читаемый ответ :)
>
> Horsun Vlad пишет:
>
>  > Ну, это же явный маразм.
>
> Про маразм - это сгоряча.

Нет, не сгоряча. В ASA параметризированные запросы теряют
половину своих преимуществ - отсутствие повторной оптимизации,
которая может быть дольше, чем сам запрос

> IMHO маразм - это использование единого плана
> для всех возможных значений параметров.

Для запросов в процедурах так оно и есть (даже! :) в ASA

> (И понятие "плохой индекс" мне тоже кажется достаточно маразматичным).

Подумай несколько раз о нём :)

> Упрощенный, но жизненный пример - отбор документов, скажем по периоду,
> складу и статусу. Есть индекс по дате, FK по складу, индекс по статусу.
> Дата более-менее равномерна, склады заметно отличаются объемом потока
> документов, а распределение по статусу вообще супер перекошенное - 99%
> закрыты и очень небольшое кол-во "в обработке". Какой индекс оптимальнее
> будет?

Это вопрос или таки пример ? :-D

>  > Берём процедуру типа
> ...
>  > ты хочешь сказать, что каждое выполнение внутреннего select'а
>  > будет оптимизтроваться заново ?
>
> Для процедур, функций и триггеров сделано "интеллектуальное" кэширование
> планов:

Да, кавычки ты к месту употребил :)

>
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm

Да, я уже это прочитал. Кстати - глубина доки по ASA
поражает - такое впечатление, что они её пишут для детсадов
и боятся (или просто не знают ?) написать что-нибудь более
сложное, чем 2х2

> Вкраце смысл: после нескольких выполнений оператора строится reusable
> план. Он не зависит от значений переменных.

Приходим туда, откуда начали

> Если стоимость такого плана
> близка к лучшей зафиксированной стоимости запроса, то план добавляется в
> кэш и используется в дальнейшем.

Это работает только если пар-ры не плавают. Рассчитывать на
это - глупо (маразм :)

> В противном случае затраты на
> оптимизацию на каждом исполнении перевешиваются выгодами от оптимизации
> и принимается решение не кэшировать, а оптимизировать каждый раз.

Ниасилил. Замени кеширование на оптимизацию в этом предложении
в некоторых местах (или наоборот) :)

> Запросы с сохраненными в кэше планами периодически переоптимизируются
> для проверки относительной эффективности сохраненного плана.
>
>  > Нафиг-нафиг такой 'оптимизатор'
>
> Никто ж не заставляет :) Просто упомянул к сведению.

Просто эта фича ASA
а) не совсем в тему того, о чём говорились,
б) весьма далека от идеала (ладно - imho :)
в) мне лично представляется весьма спорной

> P.S. Гистограммы в FB планируются? В roadmap упоминается со средним
> приоритетом  Optimizer improvements ... more data statistics

Да, конечно

-- 
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Повтор, что бы убрать спам.детектед

[Korg]

> Здравствуйте! У мня следующая ситуация: постоянно принимаю данные от
> оборудования (GPS-координаты то машин). Интервал 15-60 сек, порядка 
> 100-200
> машин. Ложу данные в историю. Если для получения последних точек шуршать 
> по
> истории, получается довольно долго, а нужно одновлять данные на экране 
> раза
> два в минуту. Сейчас одновременно с историей ложу данные в таблицу, в
> которой хранятся именно только последние точки. Всё вроде ничего, но
> IBAnalyst ругается на то, что в этой таблице слишком много версий данных:
>
> Taблицы c мнoжecтвoм вepcий
> LAST_CAR_POINT Зaпиceй: 15, вepcий: 3862, дл. вepcий 54% oт дл. зaпиceй
>
> Вопрос: правильно ли я делаю, и как надо делать правильней?



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re:

[Karabas Barabas]

Hi Alex Cherednichenko !

 AC> Дальше следует непереводимая игра слов

такими темпами скоро научат и такое читать ...

-
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re:

[Alex Cherednichenko]

Привет, Alexander!
Вы пишешь  26 июня 2006:

 >>> Optimization proper commences just before execution. If you are using
 >>> cursors in your application, optimization commences when the cursor is
 >>> opened. Unlike many other commercial database systems, Adaptive Server
 >>> Anywhere *optimizes each statement just before executing it*.

Дальше следует непереводимая игра слов
с использованием местных идиоматических выражений:

 AG> Ïðî ìàðàçì - ýòî ñãîðÿ÷à. IMHO ìàðàçì - ýòî èñïîëüçîâàíèå åäèíîãî ïëàíà
 AG> äëÿ âñåõ âîçìîæíûõ çíà÷åíèé ïàðàìåòðîâ. È ïîíÿòèå "ïëîõîé èíäåêñ" ìíå...


--
With best regards, Alex Cherednichenko.



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Вторая попытка отправить читаемый ответ :)

Horsun Vlad пишет:

 > Ну, это же явный маразм.

Про маразм - это сгоряча. IMHO маразм - это использование единого плана
для всех возможных значений параметров.(И понятие "плохой индекс" мне
тоже кажется достаточно маразматичным).
Упрощенный, но жизненный пример - отбор документов, скажем по периоду,
складу и статусу. Есть индекс по дате, FK по складу, индекс по статусу.
Дата более-менее равномерна, склады заметно отличаются объемом потока
документов, а распределение по статусу вообще супер перекошенное - 99%
закрыты и очень небольшое кол-во "в обработке". Какой индекс оптимальнее
будет?

 > Берём процедуру типа
...
 > ты хочешь сказать, что каждое выполнение внутреннего select'а
 > будет оптимизтроваться заново ?

Для процедур, функций и триггеров сделано "интеллектуальное" кэширование
планов:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm
Вкраце смысл: после нескольких выполнений оператора строится reusable
план. Он не зависит от значений переменных. Если стоимость такого плана
близка к лучшей зафиксированной стоимости запроса, то план добавляется в
кэш и используется в дальнейшем. В противном случае затраты на
оптимизацию на каждом исполнении перевешиваются выгодами от оптимизации
и принимается решение не кэшировать, а оптимизировать каждый раз.
Запросы с сохраненными в кэше планами периодически переоптимизируются
для проверки относительной эффективности сохраненного плана.

 > Нафиг-нафиг такой 'оптимизатор'

Никто ж не заставляет :) Просто упомянул к сведению.

P.S. Гистограммы в FB планируются? В roadmap упоминается со средним
приоритетом  Optimizer improvements ... more data statistics


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Horsun Vlad ïèøåò:
> http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0404.htm
>> Öèòàòà:
>>
>> Optimization proper commences just before execution. If you are using
>> cursors in your application, optimization commences when the cursor is
>> opened. Unlike many other commercial database systems, Adaptive Server
>> Anywhere *optimizes each statement just before executing it*.
> 
> Íó, ýòî æå ÿâíûé ìàðàçì. 

Ïðî ìàðàçì - ýòî ñãîðÿ÷à. IMHO ìàðàçì - ýòî èñïîëüçîâàíèå åäèíîãî ïëàíà 
äëÿ âñåõ âîçìîæíûõ çíà÷åíèé ïàðàìåòðîâ. È ïîíÿòèå "ïëîõîé èíäåêñ" ìíå 
òîæå êàæåòñÿ äîñòàòî÷íî ìàðàçìàòè÷íûì.
Óïðîùåííûé, íî æèçíåííûé ïðèìåð - îòáîð äîêóìåíòîâ, ñêàæåì ïî ïåðèîäó, 
ñêëàäó è ñòàòóñó. Åñòü èíäåêñ ïî äàòå, FK ïî ñêëàäó, èíäåêñ ïî ñòàòóñó. 
Äàòà áîëåå-ìåíåå ðàâíîìåðíà, ñêëàäû çàìåòíî îòëè÷àþòñÿ îáúåìîì ïîòîêà 
äîêóìåíòîâ, à ðàñïðåäåëåíèå ïî ñòàòóñó âîîáùå ñóïåð ïåðåêîøåííîå - 99% 
çàêðûòû è î÷åíü íåáîëüøîå êîë-âî "â îáðàáîòêå". Êàêîé èíäåêñ îïòèìàëüíåå 
áóäåò?

> Áåð¸ì ïðîöåäóðó òèïà 
...
> òû õî÷åøü ñêàçàòü, ÷òî êàæäîå âûïîëíåíèå âíóòðåííåãî select'à
> áóäåò îïòèìèçòðîâàòüñÿ çàíîâî ? 

Äëÿ ïðîöåäóð, ôóíêöèé è òðèããåðîâ ñäåëàíî "èíòåëëåêòóàëüíîå" êýøèðîâàíèå 
ïëàíîâ:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm
Âêðàöå ñìûñë: ïîñëå íåñêîëüêèõ âûïîëíåíèé îïåðàòîðà ñòðîèòñÿ reusable 
ïëàí. Îí íå çàâèñèò îò çíà÷åíèé ïåðåìåííûõ. Åñëè ñòîèìîñòü òàêîãî ïëàíà 
áëèçêà ê ëó÷øåé çàôèêñèðîâàííîé ñòîèìîñòè çàïðîñà, òî ïëàí äîáàâëÿåòñÿ â 
êýø è èñïîëüçóåòñÿ â äàëüíåéøåì.  ïðîòèâíîì ñëó÷àå çàòðàòû íà 
îïòèìèçàöèþ íà êàæäîì èñïîëíåíèè ïåðåâåøèâàþòñÿ âûãîäàìè îò îïòèìèçàöèè 
è ïðèíèìàåòñÿ ðåøåíèå íå êýøèðîâàòü, à îïòèìèçèðîâàòü êàæäûé ðàç. 
Çàïðîñû ñ ñîõðàíåííûìè â êýøå ïëàíàìè ïåðèîäè÷åñêè ïåðåîïòèìèçèðóþòñÿ 
äëÿ ïðîâåðêè îòíîñèòåëüíîé ýôôåêòèâíîñòè ñîõðàíåííîãî ïëàíà.

> Íàôèã-íàôèã òàêîé 'îïòèìèçàòîð'

Íèêòî æ íå çàñòàâëÿåò :) Ïðîñòî óïîìÿíóë ê ñâåäåíèþ.

P.S. Ãèñòîãðàììû â FB ïëàíèðóþòñÿ? Â roadmap óïîìèíàåòñÿ ñî ñðåäíèì 
ïðèîðèòåòîì  Optimizer improvements ... more data statistics




--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

����� ����������� �����

[Korg]

Здравствуйте! У мня следующая ситуация: постоянно принимаю данные от
оборудования (GPS-координаты то машин). Интервал 15-60 сек, порядка 100-200
машин. Ложу данные в историю. Если для получения последних точек шуршать по
истории, получается довольно долго, а нужно одновлять данные на экране раза
два в минуту. Сейчас одновременно с историей ложу данные в таблицу, в
которой хранятся именно только последние точки. Всё вроде ничего, но
IBAnalyst ругается на то, что в этой таблице слишком много версий данных:

Taблицы c мнoжecтвoм вepcий
LAST_CAR_POINT Зaпиceй: 15, вepcий: 3862, дл. вepcий 54% oт дл. зaпиceй

Вопрос: правильно ли я делаю, и как надо делать правильней?



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Horsun Vlad]

"Alexander Goldun" ...
> Horsun Vlad пишет:
>
> >>> HV> Спасибо,  но - где тут про автоматическую корреляцию плана запроса
> >>> HV> с параметрами в зависимости от их значенией в рантайме ?
> >>> Значит Вы будите первыми! ;-)
> > Мы спим первыми, а вы нас будите всё время :)
> >> Вторыми :)
> > Ссылка ?
>
> Да обсуждали уже. В ASA параметры влияют на план. Для меня скорее
> откровением было то, что в других серверах это не так.
>
>
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0404.htm
> Цитата:
>
> Optimization proper commences just before execution. If you are using
> cursors in your application, optimization commences when the cursor is
> opened. Unlike many other commercial database systems, Adaptive Server
> Anywhere *optimizes each statement just before executing it*.

Ну, это же явный маразм. Берём процедуру типа

create procedure xxx
as
declare d1 as date;
declare d2 as date;
begin
  d1 = '01.01.1980';
  while (d2 < '01.01.2006')
  begin
select ... where d between :d1 and :d2 into ...;
d2 = d2 + 31;
  end
end

ты хочешь сказать, что каждое выполнение внутреннего select'а
будет оптимизтроваться заново ? Нафиг-нафиг такой 'оптимизатор'

-- 
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ����������������

[Slava Ekimov]

 ??>> В /intl каталоге ничего руками не трогал?
 ??>>
 АЖ> Да нет, периодически туда накатывается новый снапшот, перезаписываются
 АЖ> все старые файлы, а вот ошибка похоже остается.

Базу пересоздать из скрипта и залить по новой. 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблицы

[Nikolay Ponomarenko]

Hello, Dmitry!
You wrote  on Mon, 26 Jun 2006 16:09:10 +0400:

 ??>> Да обсуждали уже. В ASA параметры влияют на план. Для меня скорее
 ??>> откровением было то, что в других серверах это не так.
 DY> В Оракле это так только начиная с 9i. Про остальных не в курсе.

Не точно по теме, но близко("эвристически, согласно последним значениям") и 
интересно :)

AS>Он по "предсказуемости" не дотянул...
AS>Наблюдал пример (MS 2005):
AS>есть некий запрос "SELECT ... FROM ..." — выполняется 12 секунд.
AS>Заворачиваем его "SELECT * FROM (SELECT ... FROM ...)" — выполняется 0,8 
секунды.
AS>Естественно, планы запросов разные. Но блин, на мой взгляд, это глюк 
опримизатора...
Есть такая шняга. В MSSQL решили повысить кэшируемость запросов за счет 
автоматического преобразования констант в переменные. А для переменных 
статистика берется эвристически, согласно последним значениям. Подробности 
были описаны у Merle в блобе. В случае если select ... from (select ... from 
... where id=100), константа останется константой. И планы запросов будут 
генериться согласно данной константе. Вот и разница.


PS кто нибудь знает, откуда берется utf-8 и почему бьются кирилические 
заголовки?

-- 
-=Пессимисту коньяк пахнет клопами, оптимисту - клопы коньяком=-
With best regards,  Nikolay Ponomarenko 


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Trading Reccommendation - Ashok Leyland

[DerivativeMaster.com]

 

WWW.DERIVATIVEMASTER.COM

 

[ 26th JUNE 2006 ]   Todays calls were as under :

 


  



Futures Master Plan


  
  



Reccommendation 





Lot Size





Profit / (Loss) Per Lot


  
  



Sell Ashok Leyland @ 36.80 SL 37.25 Target 35.30 





9550





+ 14,325


  



 

 

To Subscribe visit www.DerivativeMaster.com OR Mail at [EMAIL PROTECTED]

 

 

WWW.DERIVATIVEMASTER.COM

 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ������������ �����

[Dmitry Yemanov]

"Alexander Goldun" <[EMAIL PROTECTED]> wrote:
>
> Да обсуждали уже. В ASA параметры влияют на план. Для меня скорее
> откровением было то, что в других серверах это не так.

В Оракле это так только начиная с 9i. Про остальных не в курсе.


--
Дмитрий Еманов




--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Horsun Vlad пишет:

>>> HV> Спасибо,  но - где тут про автоматическую корреляцию плана запроса
>>> HV> с параметрами в зависимости от их значенией в рантайме ?
>>> Значит Вы будите первыми! ;-)
> Мы спим первыми, а вы нас будите всё время :)
>> Вторыми :)
> Ссылка ?

Да обсуждали уже. В ASA параметры влияют на план. Для меня скорее 
откровением было то, что в других серверах это не так.

http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0404.htm
Цитата:

Optimization proper commences just before execution. If you are using 
cursors in your application, optimization commences when the cursor is 
opened. Unlike many other commercial database systems, Adaptive Server 
Anywhere *optimizes each statement just before executing it*.
...
Because Adaptive Server Anywhere performs just-in-time optimization of 
each statement, *the optimizer has access to the values of host 
variables* and stored procedure variables. Hence, it makes better 
choices because it performs better selectivity analysis.



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Horsun Vlad]

"Alexander Goldun" ...
> Yuris W. Auzinsh пишет:
>
> > HV> Спасибо,  но - где тут про автоматическую корреляцию плана запроса
> > HV> с параметрами в зависимости от их значенией в рантайме ?
> > Значит Вы будите первыми! ;-)

Мы спим первыми, а вы нас будите всё время :)

> Вторыми :)

Ссылка ?

-- 
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ����������������

[Андрій Жук]

Dmitry Yemanov wrote:
> "Андр?й Жук" <[EMAIL PROTECTED]> wrote:
> 
>>Возникает нерегулярно, примерно раз в месяц :)
> 
> 
> В /intl каталоге ничего руками не трогал?
> 

Да нет, периодически туда накатывается новый снапшот, перезаписываются 
все старые файлы, а вот ошибка похоже остается.


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

[Alexander Goldun]

Yuris W. Auzinsh пишет:

> HV> Спасибо,  но - где тут про автоматическую корреляцию плана запроса
> HV> с параметрами в зависимости от их значенией в рантайме ?
> Значит Вы будите первыми! ;-)

Вторыми :)



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re[4]: Сверхбольшие таблиы

[Yuris W. Auzinsh]

Здравствуйте, Horsun Vlad.

Недавно (26 июня 2006 г., 12:49:57) Вы писали:

HV> Спасибо,  но - где тут про автоматическую корреляцию плана запроса
HV> с параметрами в зависимости от их значенией в рантайме ?
Значит Вы будите первыми! ;-)

-- 
  Удачи...
   
   Yuris W. Auzinsh aka Zuz,
   ICQ UIN: 5 8 2 5 6 3 7 4,
   e-mail : zuz(аt)mail.ru



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ��� ����� �����

[Dmitry Yemanov]

"Андр?й Жук" <[EMAIL PROTECTED]> wrote:
>
> Возникает нерегулярно, примерно раз в месяц :)

В /intl каталоге ничего руками не трогал?


--
Дмитрий Еманов




--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: FDB to MDB/TXT

[Ded]

Gui wrote:
> Sorry for using english here. The problem is I know as much russian as
> I know about Firebird.

 Gui, main FB site is http://www.firebirdsql.org/ . On page 
"Resources" you can find some support lists and newsgroups in English. 
If I'm right in assumption that your native language is French, you can 
try http://www.niouze.net .

-- 
Best regards.


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Вот такая ошибка

[Horsun Vlad]

"Андрій Жук" ...

> Характерных два

Вот и нехрен спамить остальными

-- 
Хорсун Влад



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ����������������

[Андрій Жук]

Dmitri Kuzmenko wrote:
Характерных два

ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: NONE:NONE defined in  and

и

ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: SJIS_0208:SJIS_0208 defined in C:\Program
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: : off

[Roman V. Babenko aka romb]

Karabas Barabas wrote:
> Hi Dmitry Lendel !
> 
>  DL> Баян. Да еще и такого размера
> 
> Да и не совпадает много :)
> 

Ну как проапгрейдь, а я почитаю :-)


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: ��� ����� �����

[Dmitri Kuzmenko]

Hello!

Андрий Жук wrote:

> Сервера меняю каждую неделю на последний снапшот, ошибка (по логу) 
> начала проявляться после нового года, последний раз вчера.
> 
> ZHOUCK (Server)   Sun Jun 25 21:50:15 2006
>   INTL plugin conflict: NONE:NONE defined in  and

дядя, а ты мог чутка руками пошевелить, и оставить только
характерные НЕПОВТОРЯЮЩИЕСЯ сообщения?
Что за манера, пулять лог целиком - пусть разбираются, типа,
разгребают?

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Off. Отчет о поездке в Лондон. Продолжение.

[Сергей Фетискин]

On Fri, 23 Jun 2006 18:03:54 +0400, Мадорский Г.В.  
<[EMAIL PROTECTED]> wrote:

>>>
>> Фотки классные. Чем снимал?
> Фотоапарат Sanyo какой-то там. В свое время подарили на день варенья...  
> Я в
> них особо не разбираюсь...

А модель?

-- 
Фетискин Сергей
http://stella-npf.ru


--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re[2]: Сверхбольшие таблицы

[Ruslan Bondarenko]

Hello Ded,

Wednesday, June 21, 2006, 8:05:49 PM, you wrote:

> Константин wrote:

>>   А фиг его знает, может и не хватит если ООП БД строить ...
>>   Там таблиц 1-2 и обчёлся а записи ростут чуть ли не в
>>   геометрической прогресии :(

> А доедет ли эта брика до Киева? (C) Тащусь я с 
> объектно-ориентированных всю жись :-D

Смотря где применять. Я вот в одной ЕРП вижу - "а у нас вот тут 30
аналитик, но все их еще никто не использовал". А если мне надо 35? Или
5? Ничего страшного конечно нет, но есть некоторое чувство, что
вернулся лет на 10 назад :). Было бы намного эстетичнее, если бы
сколько надо, столько и заводил, а потом универсальными средствами
(ОЛАП) проводил анализ.

-- 
Best regards,
 Ruslanmailto:[EMAIL PROTECTED]



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Off: Creation file timestamp

[Slava Ekimov]

 AAV> Простите, но что-то никгде не нарыл в хелпе и в Инете. Как можно
 AAV> изменить дату/время создания файла? D7. Файловая система - NTFS.

Win32.SetFileTime.
The SetFileTime function sets the date and time that a file was created, 
last accessed, or last modified. 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Off: Creation file timestamp

[Alexander A. Venikov]

Hello, All!

Простите, но что-то никгде не нарыл в хелпе и в Инете. Как можно изменить 
дату/время создания файла? D7. Файловая система - NTFS.

FileSetDate(...) изменяет дату/время модификации. А мне нужно установить и 
время создания, и время модификации равными дате/времени, полученными с 
FTP-сервера. Написал сервис для периодической синхронизации FTP-каталога с 
локальным каталогом, все работает, только дата создания файла равна дате 
закачки файла по FTP. Как подкрутить - не нашел, но ведь тот же FAR как-то это 
делает.

Удач
--
Alexander A. Venikov, Tobolsk, Russia
Real e-mail address is venixtntobru 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Ну вот и пятница наступила.

[Gene Feudorov]

Hello, Nikolay Ponomarenko!
You wrote to Мадорский Г.В. on Fri, 23 Jun 2006 13:58:17 +0300:

 NP> ??>>А щас модно съёмку платной делать просто везде. Фото
 NP> дешевле,
 NP> Это наверное последователи Бендера...(осмотр
 NP> Хо, у нас в Крыму сейчас берут деньги, нет, не за осмотр, а просто

да у вас там и за съёмку то завсегда брали!
я правда ни разу не платил :-)

Фёдоров Евгений.
ЗАО "Трест-М". Екатеринбург.



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Re: Off. . .

[Мадорский Г . В .]

"Slava Ekimov" <[EMAIL PROTECTED]> сообщил/сообщила 
в новостях следующее: news:[EMAIL PROTECTED]
> >При покупке билетов, кассир сказал, что так как мы покупаем 3
>> билета - нам полагается скидка. И взял с нас 32&. Блин, вот интересно, 
>> когда
>> англичане туда едут вдвоем, они догадываются покупать 3 билета? Я так
>> подозреваю что нет :).
>
> А вы не догадались купить 4 ? :-)
Догадался. Но правда позже. Спросил ради интереса. 4 билета стоят на 2& 
дороже чем 3. Вообщем там (как и у нас) на троих сподручней всего :)

With b/r. Gleb. 



--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---

Вот такая ошибка

[Андрій Жук]

Возникает нерегулярно, примерно раз в месяц :)
Помогает перезапуск сервера
Сервера меняю каждую неделю на последний снапшот, ошибка (по логу) 
начала проявляться после нового года, последний раз вчера.

ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: NONE:NONE defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: OCTETS:OCTETS defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: ASCII:ASCII defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: UNICODE_FSS:UNICODE_FSS defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: UTF8:UTF8 defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: UTF8:UCS_BASIC defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: UTF8:UNICODE defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: UTF16:UTF16 defined in  and


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: SJIS_0208:SJIS_0208 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: EUCJ_0208:EUCJ_0208 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DOS437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_DEU437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_ESP437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_FIN437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_FRA437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_ITA437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_NLD437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_SVE437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_UK437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:DB_US437 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:PDOX_ASCII defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:PDOX_INTL defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS437:PDOX_SWEDFIN defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DOS850 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DB_DEU850 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DB_ESP850 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DB_FRA850 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DB_FRC850 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DB_ITA850 defined in C:\Program 
Files\Firebird2\intl\fbintl and C:\Program Files\Firebird2\intl\fbintl


ZHOUCK (Server) Sun Jun 25 21:50:15 2006
INTL plugin conflict: DOS850:DB_NLD850 defined in C:\Progr