ИндексЫ
Подскажите можно сделать индекс не полю а например на основании udf, которая будет обрабатывать блоб? Можно сделать так что бы не все записи добавлялась в индекс? Ответ на вопрос "зачем": например в таблице очень много записей и нужно искать только небольшое количество по специфичному индексу, если будет индекс построен по всей таблице, то он просто будет слишком большим и главное он такой совсем не нужен.
Re: ИндексЫ
Привет! > Подскажите можно сделать индекс не полю а например на основании udf, которая > будет обрабатывать блоб? > Можно сделать так что бы не все записи добавлялась в индекс? > Ответ на вопрос "зачем": например в таблице очень много записей и нужно > искать только небольшое количество по специфичному индексу, если будет > индекс построен по всей таблице, то он просто будет слишком большим и > главное он такой совсем не нужен. Суть создания индекса как раз в уменьшении данных, с которыми приходится работать. Если у тебя индекс занимает столько же, сколько и сами данные - это плохой, негодный индекс ;-) Индексы по выражениям строить можно и очень часто они помогают. -- Best regards, Sergeymailto:gebele...@gmail.com
RE: ИндексЫ
Вы не поняли, повторю. Допустим есть в таблице 1 записей. Если я строю по ней индекс, то в индекс будут добавлены все записи из таблицы, т.е. все 1. Мне нужно поострить индекс в который будут добавлены, например только 7%, от общего количества записей. Просто остальные записи для поиска по этому индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит вставку новых записей в таблицу. -Original Message- From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On Behalf Of Sergey Mereutsa Sent: Monday, September 19, 2011 1:03 PM To: ru-firebird@googlegroups.com Subject: Re: ИндексЫ Привет! > Подскажите можно сделать индекс не полю а например на основании udf, которая > будет обрабатывать блоб? > Можно сделать так что бы не все записи добавлялась в индекс? > Ответ на вопрос "зачем": например в таблице очень много записей и нужно > искать только небольшое количество по специфичному индексу, если будет > индекс построен по всей таблице, то он просто будет слишком большим и > главное он такой совсем не нужен. Суть создания индекса как раз в уменьшении данных, с которыми приходится работать. Если у тебя индекс занимает столько же, сколько и сами данные - это плохой, негодный индекс ;-) Индексы по выражениям строить можно и очень часто они помогают. -- Best regards, Sergeymailto:gebele...@gmail.com
RE: ИндексЫ
Привет! >Мне нужно поострить индекс в который будут добавлены, например только 7%, от >общего количества записей. Просто остальные записи для поиска по этому >индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит >вставку новых записей в таблицу. Ну а вынести эти 7% в отдельную таблицу и построить уже по ней правильные индексы никак? WBR, Dmitry Beloshistov AKA [-=BDS=-]
Re: ИндексЫ
19.09.2011 14:33, Михаил Викторович пишет: Мне нужно поострить индекс в который будут добавлены, например только 7%, от общего количества записей. Просто остальные записи для поиска по этому индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит вставку новых записей в таблицу. Ну, так и надо сделать отдельную таблицу, связанную 1-к-1 с исходной, куда добавлять ключи требуемых записей, а в запросах на выборку эти таблицы джойнить. -- С уважением, Денис Редозубов
RE: ИндексЫ
Решение связанное с разбиением таблиц очевидное, и не интересное совсем. Вопрос про индексы остался открытым или твердое нет? -Original Message- From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On Behalf Of dennis redozubov Sent: Monday, September 19, 2011 2:52 PM To: ru-firebird@googlegroups.com Subject: Re: ИндексЫ 19.09.2011 14:33, Михаил Викторович пишет: > Мне нужно поострить индекс в который будут добавлены, например только 7%, от > общего количества записей. Просто остальные записи для поиска по этому > индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит > вставку новых записей в таблицу. Ну, так и надо сделать отдельную таблицу, связанную 1-к-1 с исходной, куда добавлять ключи требуемых записей, а в запросах на выборку эти таблицы джойнить. -- С уважением, Денис Редозубов
Re: ИндексЫ
Решение связанное с разбиением таблиц очевидное, и не интересное совсем. есть два варианта: а) разбить таблицу на две одинаковых, в одной 7%, в другой 93% б) сделать еще одну таблицу, в которой хранится только одно поле - PK из большой таблицы. те самые 7% PK В вашем случае в таблице лучше сделать два поля - PK, и значение, которое выдает udf
Re: ИндексЫ
"Михаил Викторович" ... Подскажите можно сделать индекс не полю а например на основании udf, которая будет обрабатывать блоб? Да. Можно сделать так что бы не все записи добавлялась в индекс? Нет. -- Хорсун Влад
Идентичные индексы.
Бу всем. В процессе визуального контроля результатов выполнения патча глаз зацепился за два системных уникальных индекса, висящих на одном и том же наборе колонок - (ID,CLASS) Один индекс породил первичный ключ. Второй - FK Глаз зацепился, а в башке стукнуло - почему бы серверу эти два индекса не слить в один? Если они по структуре (и содержимому) идентичны, то для сервер может для таких индексов завести счетчик использования в ограничениях? Создаем PK - смотрим есть подходящий индекс? Нет - хорошо, создаем новый. Создаем FK - смотрим, ага есть подходящий индекс. Увеличиваем счетчик использования. Или оно и так на самом деле сделано, и я открыл Америку? :) Коваленко Дмитрий.
Сыплются индексы :-((
FB 1.5.3 CS Не далее как в прошлую субботу сделал бэкап-рестор базы, и вот сегодня опять битые индексы :-((( В логе вроде ничего интересного, разве что вот это: NSH Mon Jun 26 09:21:29 2006 page 869734, page type 5 lock conversion denied (215) но это было только один раз, иногда возникают NSH Mon Jun 26 09:38:19 2006 INET/inet_error: read errno = 10054 NSH Tue Jun 27 10:22:53 2006 SERVER/process_packet: broken port, server exiting и вот сегодня ночью при валидации обнаружилось: NSH Fri Jun 30 02:09:22 2006 Index 2 is corrupt on page 1162880 in table SERIALS (149) NSH Fri Jun 30 02:09:23 2006 Index 3 is corrupt on page 1163456 in table SERIALS (149) NSH Fri Jun 30 02:09:23 2006 Index 3 has orphan child page at page 1163456 in table SERIALS (149) От чего это может, блин, быть? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Индексы и ХП
Доброго дня подскажите ответ на возможно глупый вопрос? Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит? Заранее спасибо. -- Don`t drink and drive, smoke and fly!
Re: Идентичные индексы.
Kovalenko Dmitry wrote: Или оно и так на самом деле сделано, и я открыл Америку? :) Не сделано. Но когда-нибудь будет. Возможно :-) -- Дмитрий Еманов
Re: Сыплются индексы :-((
> но это было только один раз, иногда возникают > NSH Mon Jun 26 09:38:19 2006 > INET/inet_error: read errno = 10054 > NSH Tue Jun 27 10:22:53 2006 > SERVER/process_packet: broken port, server exiting > и вот сегодня ночью при валидации обнаружилось: > NSH Fri Jun 30 02:09:22 2006 > Index 2 is corrupt on page 1162880 in table SERIALS (149) > NSH Fri Jun 30 02:09:23 2006 > Index 3 is corrupt on page 1163456 in table SERIALS (149) > NSH Fri Jun 30 02:09:23 2006 > Index 3 has orphan child page at page 1163456 in table SERIALS (149) > > От чего это может, блин, быть? Как вариант отвалившийся процесс классика при работе с индексом. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Oleg LOA wrote: > Как вариант отвалившийся процесс классика при работе с индексом. если они сыплются из-за этого: >>NSH Mon Jun 26 09:38:19 2006 >>INET/inet_error: read errno = 10054 >>NSH Tue Jun 27 10:22:53 2006 >>SERVER/process_packet: broken port, server exiting то это по крайней мере странно: обрыв коннекта должен быть чуть ли не штатной ситуацией. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Konstantin R. Beliaev wrote: > От чего это может, блин, быть? От киляния процессов. Перед ночным майнтенансом например. -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
D> Konstantin R. Beliaev wrote: > От чего это может, блин, быть? D> От киляния процессов. Перед ночным майнтенансом например. если из-за того индексы падают, то что-то тут не то с классиком. Чтобы не говорили, но килять то приходится. Это можно считать штатной ситуацией, хоть и безвыходной. -- С уважением Кочмин Александр --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Alexandr Kochmin wrote: > если из-за того индексы падают, то что-то тут не то с классиком. А супера если десяток раз подряд завалить - всё будет чики-чики? ;) -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > Alexandr Kochmin wrote: > > > если из-за того индексы падают, то что-то тут не то с классиком. > >А супера если десяток раз подряд завалить - всё будет чики-чики? ;) Так в том то и беда, что должно быть, а нету... --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Dmitry Voroshin wrote: >>>если из-за того индексы падают, то что-то тут не то с классиком. >> >> А супера если десяток раз подряд завалить - всё будет чики-чики? ;) > > > Так в том то и беда, что должно быть, а нету... Доктор, когда я делаю вот так, мне почему-то больно ;) У меня уже года три на боевом процессы не киляются никогда. И ничо, жив пока. -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
D> Dmitry Voroshin wrote: >>>если из-за того индексы падают, то что-то тут не то с D> классиком. D> >> D> >> А супера если десяток раз подряд завалить - всё будет чики-чики? D> >> ;) D>> D>> Так в том то и беда, что должно быть, а нету... D>Доктор, когда я делаю вот так, мне почему-то больно ;) У меня уже D> года три на боевом процессы не киляются никогда. И ничо, жив пока. а как тогда всех отключать от сервера? -- С уважением Кочмин Александр --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
D> Alexandr Kochmin wrote: > если из-за того индексы падают, то что-то тут не то с D> классиком. D>А супера если десяток раз подряд завалить - всё будет чики-чики? ;) у супера нормально работает shutdown -- С уважением Кочмин Александр --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > Dmitry Voroshin wrote: > > >>>если из-за того индексы падают, то что-то тут не то с классиком. > >> > >> А супера если десяток раз подряд завалить - всё будет чики-чики? ;) > > > > > > Так в том то и беда, что должно быть, а нету... > >Доктор, когда я делаю вот так, мне почему-то больно ;) У меня уже > года три на боевом процессы не киляются никогда. И ничо, жив пока. Ну знаешь. Всё таки это баг и должен потихоньку правиться. Порча БД сервером всё таки одна из самых опасных проблем. Причём неважно при каких обстоятельствах это происходит (я не беру в учёт кривое железо - тут уж ничего не поделаешь). --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Alexandr Kochmin wrote: > D>Доктор, когда я делаю вот так, мне почему-то больно ;) У меня уже > D> года три на боевом процессы не киляются никогда. И ничо, жив пока. > > а как тогда всех отключать от сервера? А зачем? Чтоб под ногами не путались достаточно шатдауна и фиг с ним что болтаются, ничего сделать не могут. А действительно разгонять надо очень редко. Если серьёзно надо покурочить метаданные - не впадлу и громким матом, удалённых клиентов отсекаю остановкой аппсерверов, они напрямую к базе не лезут. А замещение базы - ну раз в год для профилактики, да и то... -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > Alexandr Kochmin wrote: > > > D>Доктор, когда я делаю вот так, мне почему-то больно ;) У меня уже > > D> года три на боевом процессы не киляются никогда. И ничо, жив пока. > > > > а как тогда всех отключать от сервера? > > А зачем? Чтоб под ногами не путались достаточно шатдауна и фиг с ним > что болтаются, ничего сделать не могут. А действительно разгонять надо > очень редко. Если серьёзно надо покурочить метаданные - не впадлу и > громким матом Для мата талант нужен... Эх... --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Yurij wrote: >>а как тогда всех отключать от сервера? > > > tcpview соединение прикрыть, сервер сам и закроется. Не буду спорить про винду и супер, но пИнгвин-классике выгрузка xinetd пофиг. Не работают, но висят, как и при шатдауне. -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Alexandr Kochmin wrote: > D> Alexandr Kochmin wrote: > если из-за того индексы падают, то что-то тут > не то с > D> классиком. > D>А супера если десяток раз подряд завалить - всё будет чики-чики? ;) > > у супера нормально работает shutdown Взаправду? :-D Двойку я ещё не тряс правда. -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Dmitri Kuzmenko wrote: >>Ну знаешь. Всё таки это баг и должен потихоньку правиться. Порча БД сервером >>всё таки одна из самых опасных проблем. Причём неважно при каких >>обстоятельствах это происходит (я не беру в учёт кривое железо - тут уж >>ничего не поделаешь). > > > что значит "неважно"? Ресет сервера что, должен проходить гладко > и безболезненно? Особенно когда Forced Write = OFF? > > Сервер это ПО, которое работает в контексте операционки, > которая работает в контексте драйверов и железа. Так что, > не надо про "это баг и должен потихоньку правиться". Вообще-то, по идее, ничего кроме орфанов при этом получаться не должно, во всяком случае при FW On. Так что таки баг и таки потихоньку правится. Ловить такие вещи - сам знаешь. Поскольку в контексте, ещё пёс его знает чей баг :) Ну а кто без бага, пусть первый бросит в меня спамом (С), я слышал от Ковязина :) -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > Alexandr Kochmin wrote: > > > D> Alexandr Kochmin wrote: > если из-за того индексы падают, то что-то тут не то с > > D> классиком. > > D>А супера если десяток раз подряд завалить - всё будет чики-чики? ;) > > > > у супера нормально работает shutdown > > Взаправду? :-D Двойку я ещё не тряс правда. Вроде правда. У меня. На двойке. Но надо на пользователях экспернимент поставить :))) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
On Fri, 30 Jun 2006 14:25:50 +0400, Dmitry Voroshin <[EMAIL PROTECTED]> wrote: > > Для мата талант нужен... Эх... > Говорят в армии готовят отличных специалистов :) -- Фетискин Сергей http://stella-npf.ru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Dmitri Kuzmenko wrote: >Вообще-то, по идее, ничего кроме орфанов при этом получаться не > должно, во всяком случае при FW On. Так что таки баг и таки потихоньку FW и процесс прибиения процесса классика/серевера с разрушением БД никак не связан ;-) > правится. Ловить такие вещи - сам знаешь. Поскольку в контексте, ещё пёс > его знает чей баг :) Ну а кто без бага, пусть первый бросит в меня > спамом (С), я слышал от Ковязина :) Скорее процесс отвалилися недописав что-то в индекс. Вопрос почему? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
D> Alexandr Kochmin wrote: > D>Доктор, когда я делаю вот так, мне почему-то D> больно ;) У меня уже D>>> года три на боевом процессы не киляются никогда. И ничо, жив пока. D>> D>> а как тогда всех отключать от сервера? D> А зачем? так чтоб базу обновить. FK например, да и вообще. Да хоть даже сервер перегрузить просто. D> Чтоб под ногами не путались достаточно шатдауна и фиг с ним что болтаются, ничего сделать не могут. А действительно разгонять D> надо очень редко. Если серьёзно надо покурочить метаданные - не впадлу и D> громким матом, значит один выход: встраивать прямо в программу такой мат. D> удалённых клиентов отсекаю остановкой аппсерверов, они напрямую к базе не лезут. А замещение базы - ну раз в год для D> профилактики, да и то... -- С уважением Кочмин Александр --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
D> Alexandr Kochmin wrote: > D> Alexandr Kochmin wrote: > если из-за того индексы D> падают, то что-то тут не то с D>>> классиком. D>>>А супера если десяток раз подряд завалить - всё будет чики-чики? D>>> ;) D>> D>> у супера нормально работает shutdown D> Взаправду? :-D Двойку я ещё не тряс правда. хм... я имею в виду gfix - shutdown а не остановку сервиса. -- С уважением Кочмин Александр --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Ded wrote: >>От чего это может, блин, быть? > От киляния процессов. Перед ночным майнтенансом например. Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока не было, а вот индексы продолжают падать. Да, у меня 1й диалект, если это имеет значение. Перевод базы на 3й не представляется возможным из-за размеров. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Ded wrote: > А зачем? Чтоб под ногами не путались достаточно шатдауна У меня есть подозрение, что шатдаун длинного запроса небезопасен. Не уверен, что из-за этого, но несколько раз у меня на классике зависал блокировщик, и ситуация была именно такая: длинный запрос + шатдаун. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Dmitry Voroshin wrote: > Для мата талант нужен... Эх... Ded-у надо выпустить цитатник ;)) Что-то типа "Как отключить всех юзеров от базы за 5 минут без помощи рук" --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Konstantin R. Beliaev wrote: >>От киляния процессов. Перед ночным майнтенансом например. > > Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока > не было, а вот индексы продолжают падать. Тряси железо. Начинай с RAM. -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Konstantin R. Beliaev wrote: > >>>От киляния процессов. Перед ночным майнтенансом например. >> >> Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока >> не было, а вот индексы продолжают падать. > >Тряси железо. Начинай с RAM. Помнишь обсуждение проблем с классиком YA на SQL.RU. Возможно у него такая же проблема. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Oleg LOA wrote: > Помнишь обсуждение проблем с классиком YA на SQL.RU. Возможно у него такая же > проблема. А можно ссылку? Или краткое резюме? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Konstantin R. Beliaev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Oleg LOA wrote: >> Помнишь обсуждение проблем с классиком YA на SQL.RU. Возможно у него такая >> же проблема. > А можно ссылку? Или краткое резюме? Резюме - ошибка в коде блокировщика --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Oleg LOA wrote: > Резюме - ошибка в коде блокировщика Дурацкий вопрос: а при сборке мусора индексы обновляются? Например, при чистке версий удаленных записей. Корректно ли обработается ситуация если в процессе этой самой сборки оборвался коннект? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Konstantin R. Beliaev" ... > Oleg LOA wrote: > > Резюме - ошибка в коде блокировщика > > Дурацкий вопрос: а при сборке мусора индексы обновляются? Например, при > чистке версий удаленных записей. Да > Корректно ли обработается ситуация если в процессе этой самой сборки > оборвался коннект? Максимум что будет - лишние записи в индексе и\или orphan pages. По идее :) -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Horsun Vlad wrote: > Максимум что будет - лишние записи в индексе и\или orphan pages. > По идее :) А на практике? ;-) Насколько понимаю, именно это и будет рассматриваться GFIX-ом как "index corrupt", так? Как раз про orphan pages в индексе он что-то и говорил. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Konstantin R. Beliaev" ... > Horsun Vlad wrote: > > Максимум что будет - лишние записи в индексе и\или orphan pages. > > По идее :) > А на практике? ;-) С FW=ON так и должно быть. Практика у тебя у самого есть :) Я такое не практикую > Насколько понимаю, именно это и будет рассматриваться GFIX-ом как "index > corrupt", так? Как раз про orphan pages в индексе он что-то и говорил. Orphan page - это совершенно не критичная ошибка. Так-с, ещё раз перечитываю вопрос : -- Корректно ли обработается ситуация если в процессе этой самой сборки оборвался коннект? -- Если просто оборвался коннект, то последствий вообще не должно быть. Если же его оборвали (убили процесс сервера, неважно CS или SS), то см.выше -- Хорсун Влад PS Все это элементарно проверяется самостоятельно --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >С FW=ON так и должно быть. Практика у тебя у самого есть :) > Я такое не практикую А при чём тут FW=ON? > Корректно ли обработается ситуация если в процессе этой самой сборки > оборвался коннект? > -- > >Если просто оборвался коннект, то последствий вообще не > должно быть. Если же его оборвали (убили процесс сервера, Однако практика показывает что оин могут быть ;-) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Oleg LOA" ... > "Horsun Vlad" ... > >С FW=ON так и должно быть. Практика у тебя у самого есть :) > > Я такое не практикую > > А при чём тут FW=ON? Много страниц в кеше болтается > > Корректно ли обработается ситуация если в процессе этой самой сборки > > оборвался коннект? > > -- > > > >Если просто оборвался коннект, то последствий вообще не > > должно быть. Если же его оборвали (убили процесс сервера, > > Однако практика показывает что оин могут быть ;-) Я же и не говорю что этого не бывает :) Но если процесс завершился сам, то всё должно быть ок - я сильно удивлюсь, если у нас это не так -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Много страниц в кеше болтается В каком кэше? Вы там в двойке время сбрасыаиня кэша FB (не кэша ОС) сделали зависимым от FW? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Oleg LOA" ... > "Horsun Vlad" ... > >Много страниц в кеше болтается > > В каком кэше? Вы там в двойке время сбрасыаиня кэша FB (не кэша ОС) сделали зависимым от FW? Нет. Но страницы пишутся по коммиту, коего не бывает у фоновой сборки мусора. К классику, есс-но, это не относится, посему для него последствий меньше должно быть. -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Нет. Но страницы пишутся по коммиту, коего не бывает > у фоновой сборки мусора. К классику, есс-но, это не относится, > посему для него последствий меньше должно быть. Всё равно если не падает ОС, то при чём тут FW? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Oleg LOA wrote: >> Если просто оборвался коннект, то последствий вообще не >>должно быть. Если же его оборвали (убили процесс сервера, > > > Однако практика показывает что оин могут быть ;-) Однако, я от тебя это слышу уже лет 5, но вживую ни разу такого не наблюдал. А у меня это не так чтоб рутинная практика, но нередко. В приложениях если возникает непредусмотренный нами exception, то выполняется попытка отцепиться и потом Application.Terminate, никаких поэтических вольностей проге в непредусмотренных режимах. А про отладку я ваще молчу. И ничо такого не замечали... -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Oleg LOA" ... > "Horsun Vlad" ... > >Нет. Но страницы пишутся по коммиту, коего не бывает > > у фоновой сборки мусора. К классику, есс-но, это не относится, > > посему для него последствий меньше должно быть. > > Всё равно если не падает ОС, то при чём тут FW? Кеш птицы пишется в кеш ОС намного дольше, при включенном FW. Вот и не успевает, при падении процесса. Пишется он или после окончания сборки мусора (сразу много страниц), или при нехватке страниц в кеше (постепенно, по мере их вытеснения). -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" ... >Кеш птицы пишется в кеш ОС намного дольше, при включенном FW. > Вот и не успевает, при падении процесса. Пишется он или после окончания > сборки мусора (сразу много страниц), или при нехватке страниц в кеше > (постепенно, по мере их вытеснения). Тоды запишем иначе - при включенном FW, вероятность сбоя больше :-):-):-). А вообще всё это фигня. Какой там размер кэша у классика??? ;-);-);-);-);-) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Однако, я от тебя это слышу уже лет 5, но вживую ни разу такого не > наблюдал. А у меня это не так чтоб рутинная практика, но нередко. В > приложениях если возникает непредусмотренный нами exception, то Пишешь простую тест систму - типа TPCR,запускаешь процессов 200 которые интенисвно насилуют базу обновлениями/удалениями. Отрубаешь нахрен сетевые интерфейсы - и так до несколько раз. Далее тестируешь БД. Лет 5-ть ому назад это приводило к гарантированному повреждению БД, с тех пор уже много чего исправили. Но дать 100 гарантию того, что в коде всё ещё нет ошибок я не могу. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
"Oleg LOA" ... > "Horsun Vlad" ... > > "Oleg LOA" ... > >Кеш птицы пишется в кеш ОС намного дольше, при включенном FW. > > Вот и не успевает, при падении процесса. Пишется он или после окончания > > сборки мусора (сразу много страниц), или при нехватке страниц в кеше > > (постепенно, по мере их вытеснения). > > Тоды запишем иначе - при включенном FW, вероятность сбоя больше :-):-):-). Ну, собственно это я и имел в виду :) > А вообще всё это фигня. Какой там размер кэша у классика??? ;-);-);-);-);-) Да, классик меньше подвержен таким сбоям - у него и фоновой сборки нет. Я вроде другого и не писал :) -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сыплются индексы :-((
Oleg LOA wrote: > Пишешь простую тест систму - типа TPCR,запускаешь процессов 200 которые > интенисвно насилуют базу обновлениями/удалениями. Отрубаешь нахрен сетевые > интерфейсы - и так до несколько раз. Далее тестируешь БД. Вот-вот, TPC система, клиентов под сотню, 6 транзакций в день > Лет 5-ть ому назад это приводило к гарантированному повреждению БД, с тех пор > уже много чего исправили. Но дать 100 гарантию того, что в коде всё ещё нет > ошибок я не могу. :-((( --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Индексы и ХП
16.03.2011 17:14, Alexey Voychehovich пишет: Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит? Либо перекомпиляция, либо переконнект. -- Дмитрий Еманов
Re: Индексы и ХП
Спасибо 16.03.2011 16:30 пользователь "Dmitry Yemanov" написал: > 16.03.2011 17:14, Alexey Voychehovich пишет: >> >> Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит? > > Либо перекомпиляция, либо переконнект. > > > -- > Дмитрий Еманов >
Re: Индексы и ХП
Hello, Alexey! Alexey Voychehovich wrote: Доброго дня подскажите ответ на возможно глупый вопрос? Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит? если ХП уже сидит в памяти, и для нее планы созданы, то разумеется нет. поможет реконнект. И да, в процедуре у запросов планы не зашиты (если они не указаны явно). См. FAQ. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Опять про неуникальные индексы
Понятно, что сильно неуникальный индекс - это плохо, вопрос: насколько? Точнее: если у таблицы имеется индекс с селективностью, ну, скажем, 0.1, и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать влияние на скорость апдейта или нет? Вопрос вырос из размышлений: создавать ли FK на справочник, в котором порядка 10 значений, или обойтись триггерами.
Autoreply: Re: Сыплются индексы :-((
Sn: Yetkili, İş Ortaklığı Davetimizdir. Konu: Mısır Kurutma-Çeltik Kurutma ÇELTİK KURUTMA Uzun yıllardır üretmekte olduğumuz proje ve patenti firmamıza ait olan Çeltik Kurutma Makinalarını, yurt içinde siz değerli iş ortaklarımıza satışa sunulmuştur. Ülkemizdeki satış organizasyonumuza ulaşmanızdan onur duyarız. Günümüz dünya ekonomisinde, piyasa şartlarının ağır olması ve rekabet ortamının yoğunluğuna rağmen satış ve tanıtım fiyatlarımız ile sizlere istikrarlı ve karlı bir ticaret sağlayabilmek için çok özel fiyatlar ile sizleri iş ortaklığımıza davet ediyoruz. Saygılarımızla YETSAN PAZARLAMA Aykut COSKUN [EMAIL PROTECTED] 0555 563 0548 0262 724 87 80 -81 MISIR KURUTMA, ÇELTİK KURUTMA, FINDIK KURUTMA, BİBER KURUTMA, SEBZE KURUTMA, ATIK KURUTMA, ARITMA ÇAMURU KURUTMA , TUZ KURUTMA, MELAS KURUTMA, PANCAR MELASI KURUTMA. KAYSI KURUTMA, PRİNA KURUTMA, ZEYTİN KARA SU KURUTMA. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Autoreply: Re: Сыплются индексы :-((
Sn: Yetkili, İş Ortaklığı Davetimizdir. Konu: Mısır Kurutma-Çeltik Kurutma ÇELTİK KURUTMA Uzun yıllardır üretmekte olduğumuz proje ve patenti firmamıza ait olan Çeltik Kurutma Makinalarını, yurt içinde siz değerli iş ortaklarımıza satışa sunulmuştur. Ülkemizdeki satış organizasyonumuza ulaşmanızdan onur duyarız. Günümüz dünya ekonomisinde, piyasa şartlarının ağır olması ve rekabet ortamının yoğunluğuna rağmen satış ve tanıtım fiyatlarımız ile sizlere istikrarlı ve karlı bir ticaret sağlayabilmek için çok özel fiyatlar ile sizleri iş ortaklığımıza davet ediyoruz. Saygılarımızla YETSAN PAZARLAMA Aykut COSKUN [EMAIL PROTECTED] 0555 563 0548 0262 724 87 80 -81 MISIR KURUTMA, ÇELTİK KURUTMA, FINDIK KURUTMA, BİBER KURUTMA, SEBZE KURUTMA, ATIK KURUTMA, ARITMA ÇAMURU KURUTMA , TUZ KURUTMA, MELAS KURUTMA, PANCAR MELASI KURUTMA. KAYSI KURUTMA, PRİNA KURUTMA, ZEYTİN KARA SU KURUTMA. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Композитные индексы и оптимизатор
"Alexey Popov" ... Вот тут я не нашёл описания низкоуровневых подробностей. Битовая маска строится для всей таблицы целиком? Означает ли построение битовой маски что надо прочитать все страницы индекса? Сканируется диапазон ключей индекса и все найденные номера записей помещаются в разреженный битмап. -- Хосрун Влад
Re: Композитные индексы и оптимизатор
"Alexey Popov" ... Vlad Khorsun wrote: Сканируется диапазон ключей индекса и все найденные номера записей помещаются в разреженный битмап. Что то не понимаю как технически устроена эта карта. Битмап это массив бит. Как туда можно поместить номера? Эти биты сами пронумерованы :) 00010011 - битовая карта, в которой установлены биты 0, 1 и 4 Это аналог сортированного массива из целых чисел 0, 1 и 4 Номера это DB_KEY? Не совсем -- Хорсун Влад
Re: Композитные индексы и оптимизатор
"Alexey Popov" ... Vlad Khorsun wrote: Эти биты сами пронумерованы :) 00010011 - битовая карта, в которой установлены биты 0, 1 и 4 Это аналог сортированного массива из целых чисел 0, 1 и 4 Да, я так и думал. Остаётся понять в каком порядке идут эти биты - согласно индексу от ниаменьших значений к наибольшим? Какая разница ? Да и разреженный битовый массив устроен несколько сложнее. Однако чтобы слить битовые маски из двух разных индексов надо иметь одинаковых порядок записей в обоих масках. Ага, он у нас от фазы луны зависит, спасибо за подсказку :-D -- Хорсун Влад
Re: Композитные индексы и оптимизатор
"Dmitri Kuzmenko" ... where a = 5 and b = 10 при отдельных индексах по a и b 1. будет построена битовая маска по a 2. будет построена битовая маска по b 3. обе битовые маски будут слиты операцией AND 2 и 3 давно уже делаются как одно действие, потребляя меньше памяти и CPU. -- Хорсун Влад
FB 2.0, индексы по строкам
Есть БД, изначально создана на FB 1.5 Вчера попробовал перевести на 2.0. Возникла ошибка при индексном поиске по VARCHAR Упростил БД до минимума CREATE DOMAIN DID AS INTEGER NOT NULL; CREATE DOMAIN DSTRING10N AS VARCHAR(10) DEFAULT '' COLLATE WIN1251_UA; CREATE TABLE DOC ( ID DID NOT NULL, NUM_PP DSTRING10N COLLATE WIN1251_UA ); ALTER TABLE DOC ADD CONSTRAINT PK_DOC PRIMARY KEY (ID); CREATE INDEX DOC_NUMPP ON DOC (NUM_PP); - Статистика БД Database header page information: Flags 0 Checksum12345 Generation 71 Page size 16384 ODS version 11.0 Oldest transaction 63 Oldest active 64 Oldest snapshot 64 Next transaction65 Bumped transaction 1 Sequence number 0 Next attachment ID 0 Implementation ID 16 Shadow count0 Page buffers0 Next header page0 Database dialect3 Creation date Nov 29, 2006 14:34:41 Attributes force write Variable header data: Sweep interval: 2 *END* Database file sequence: File D:\GDB\LLK3_1.FDB is the only file Analyzing database pages ... DOC (128) Primary pointer page: 135, Index root page: 136 Average record length: 11.14, total records: 30119 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 94, data page slots: 94, average fill: 55% Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 93 60 - 79% = 0 80 - 99% = 0 Index DOC_NUMPP (1) Depth: 2, leaf buckets: 7, nodes: 30119 Average data length: 0.16, total dup: 25509, max dup: 254 Fill distribution: 0 - 19% = 1 20 - 39% = 0 40 - 59% = 0 60 - 79% = 0 80 - 99% = 6 Index PK_DOC (0) Depth: 2, leaf buckets: 12, nodes: 30119 Average data length: 1.77, total dup: 0, max dup: 0 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 0 60 - 79% = 0 80 - 99% = 12 -- Теперь собственно запрос select * from doc where (NUM_PP = '') or (NUM_PP is NULL) Возвращает, в зависимости от размера страницы от 32 записи для (16K) до ~762 для 1K Запрос (без использования индексов) select * from doc where coalesce(NUM_PP,'') = '' Возвращает, 26819. select * from doc where (NUM_PP||'' = '') or (NUM_PP||'' is NULL) - так тоже 26819 Есть архив fbk (rar) 116K P.S. FB 2.0 Release, WinXP + SP2
Re: Опять про неуникальные индексы
"Konstantin R. Beliaev" ... > > и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать > влияние на скорость апдейта или нет? Никакой индекс не изменяется, если не изменяется его ключ. В ОДС10 селективность индекса вообще не влияет на операцию вставки ключа, ибо номер записи вставляются в начало цепочки дубликатов ключа. В ОДС11 цепочки дубликатов отсортированны, так что вставка будет чуть медленнее, но это затраты CPU, затраты IO не изменились -- Хорсун Влад
Re: Опять про неуникальные индексы
Horsun Vlad wrote: и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать влияние на скорость апдейта или нет? Никакой индекс не изменяется, если не изменяется его ключ. Я несколько запутался: при апдейте добавляется новая версия записи. Разве индекс не меняется так чтобы указывать на эту новую версию? Или он указывает на начало цепочки версий и обновляется уже при сборке мусора? В ОДС10 селективность индекса вообще не влияет на операцию вставки ключа, ибо номер записи вставляются в начало цепочки дубликатов ключа. А в ODS 8?
Re: FB 2.0, индексы по строкам
Архив БД здесь http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Re: FB 2.0, индексы по строкам
Шавлюк Евгений wrote: Есть архив fbk (rar) 116K Кидай мне архив на firebird2 at yandex dot ru. -- Дмитрий Еманов
Re: FB 2.0, индексы по строкам
Архив БД здесь http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Re: FB 2.0, индексы по строкам
Шавлюк Евгений wrote: Архив БД здесь http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar Спасибо, воспроизвел. -- Дмитрий Еманов
Re: FB 2.0, индексы по строкам
Пока не починили и не вышел 2.0.1 можно использовать DESC индексы, если обстоятельства позволяют. В них этой баги быть не должно -- Хорсун Влад
Re: FB 2.0, индексы по строкам
Спасибо, я пока отказался от этого индекса вообще -- Шавлюк Евгений
FB 2.0, индексы по integer (is null)
Я опять здесь. Урожайный у меня день сегодня И так FB 2.0 есть запрос select d.id, i.name from docdet d left join item i on i.id = d.id_item where d.ID_DOC = :mas_id and d.i2 is null Я пользуюсь FIB, довольно старой версией. Естественно, установленно Option.poNoForceIsNull = false т.е. запрос при MAS_ID = null преобразовывается к виду select d.id, i.name from docdet d left join item i on i.id = d.id_item where d.ID_DOC is null and d.i2 is null PLAN JOIN (D NATURAL, I INDEX (PK_ITEM)) Зачем мне этот парамет нужен, не знаю, точнее но мне не нужен, но он есть. если я меняю местами выражения в "where" select d.id, i.name from docdet d left join item i on i.id = d.id_item where d.i2 is null and d.ID_DOC is null то получаю совсем другой план PLAN JOIN (D INDEX (FK_DOCDET), I INDEX (PK_ITEM)) Т.е. от перемены мест слагаемых сумма меняется? Свои ошибки уже исправил, но осадок... Про таблицы ITEM (150) Primary pointer page: 195, Index root page: 196 Average record length: 85.77, total records: 8511 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 133, data page slots: 133, average fill: 81% Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 0 60 - 79% = 4 80 - 99% = 128 Index ITEM_IDX1 (1) Depth: 2, leaf buckets: 5, nodes: 8511 Average data length: 0.19, total dup: 6992, max dup: 92 Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 0 60 - 79% = 0 80 - 99% = 4 Index ITEM_ITEM (0) Depth: 2, leaf buckets: 5, nodes: 8511 Average data length: 0.29, total dup: 6926, max dup: 253 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 1 60 - 79% = 0 80 - 99% = 4 Index PK_ITEM (2) Depth: 2, leaf buckets: 7, nodes: 8511 Average data length: 1.64, total dup: 0, max dup: 0 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 1 60 - 79% = 0 80 - 99% = 6 DOCDET (160) Primary pointer page: 217, Index root page: 218 Average record length: 63.26, total records: 1928535 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 24766, data page slots: 24767, average fill: 77% Fill distribution: 0 - 19% = 81 20 - 39% = 0 40 - 59% = 2 60 - 79% = 24683 80 - 99% = 0 Index DOCDET_IDX1 (1) Depth: 3, leaf buckets: 1491, nodes: 1928535 Average data length: 0.44, total dup: 1139222, max dup: 113325 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 421 60 - 79% = 0 80 - 99% = 1070 Index FK_DOCDET (2) Depth: 3, leaf buckets: 1198, nodes: 1928535 Average data length: 0.03, total dup: 1898510, max dup: 23012 Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 3 60 - 79% = 2 80 - 99% = 1192 Index PK_DOCDET (0) Depth: 3, leaf buckets: 1439, nodes: 1928535 Average data length: 1.03, total dup: 0, max dup: 0 Fill distribution: 0 - 19% = 1 20 - 39% = 0 40 - 59% = 2 60 - 79% = 1 80 - 99% = 1435 CREATE TABLE DOCDET ( ID DID /* DID = INTEGER NOT NULL */, ID_DOC DID /* DID = INTEGER NOT NULL */, ID_ITEM DID NOT NULL /* DID = INTEGER NOT NULL */, ITEM_COUNT DINT /* DINT = INTEGER */, ITEMS DCOUNT /* DCOUNT = NUMERIC(9,2) */, PRICE DCURRENCY /* DCURRENCY = NUMERIC(9,2) */, ITEM_COUNT_ALT DINT /* DINT = INTEGER */, ITEMS_ALT DCOUNT /* DCOUNT = NUMERIC(9,2) */, COMMENT DSTRINGN COLLATE WIN1251_UA /* DSTRINGN = VARCHAR(50) DEFAULT '' */, ID_BARCODE DINT /* DINT = INTEGER */, SYSDAY DSYSDATE /* DSYSDATE = TIMESTAMP DEFAULT CURRENT_TIMESTAMP */, SYSUSER DSYSUSER /* DSYSUSER = VARCHAR(12) DEFAULT CURRENT_USER */, SYSREGION DSYSREGION /* DSYSREGION = INTEGER DEFAULT 1 */, I1 DINT /* DINT = INTEGER */, I2 DINT /* DINT = INTEGER */, I3 DINT /* DINT = INTEGER */, I4 DINT /* DINT = INTEGER */, D1 DDOUBLE /* DDOUBLE = DOUBLE PRECISION */, N1 DCURRENCY4 /* DCURRENCY4 = NUMERIC(12,4) */ ); ALTER TABLE DOCDET ADD CONSTRAINT PK_DOCDET PRIMARY KEY (ID); ALTER TABLE DOCDET ADD CONSTRAINT FK_DOCDET FOREIGN KEY (ID_DOC) REFERENCES DOC (ID) ON DELETE CASCADE; CREATE INDEX DOCDET_IDX1 ON DOCDET (ID_BARCODE); CREATE TABLE ITEM ( ID DID NOT NULL /* DID = INTEGER NOT NULL */, ID_ITEM DINT default 0 /* DINT = INTEGER */, ITEM_TYPE DINT /* DINT = INTEGER */, CODEDIN
Re: FB 2.0, индексы по integer (is null)
Статистику индексов лучше пожи
Re: FB 2.0, индексы по integer (is null)
Шавлюк Евгений wrote: select d.id, i.name from docdet d left join item i on i.id = d.id_item where d.ID_DOC is null and d.i2 is null PLAN JOIN (D NATURAL, I INDEX (PK_ITEM)) если я меняю местами выражения в "where" select d.id, i.name from docdet d left join item i on i.id = d.id_item where d.i2 is null and d.ID_DOC is null то получаю совсем другой план PLAN JOIN (D INDEX (FK_DOCDET), I INDEX (PK_ITEM)) Т.е. от перемены мест слагаемых сумма меняется? Тоже примерчик хотелось бы. Оптимизатор что-то ступил. -- Дмитрий Еманов
Re: FB 2.0, индексы по integer (is null)
PK_DOCDET 0.0051852833849 FK_DOCDET 0.3330557956360 DOCDET_IDX1 0.0126692452795 ITEM_ITEM 0.00063091481570154 ITEM_IDX1 0.00065832783002406 PK_ITEM 0.00011749500845326
Re: FB 2.0, индексы по integer (is null)
Пример разделил на 5 частей (вместе 4.5M) http://hdd.shavluk.googlepages.com/LLK3_docdet.part01.rar http://hdd.shavluk.googlepages.com/LLK3_docdet.part02.rar http://hdd.shavluk.googlepages.com/LLK3_docdet.part03.rar http://hdd.shavluk.googlepages.com/LLK3_docdet.part04.rar http://hdd.shavluk.googlepages.com/LLK3_docdet.part05.rar Запрос select d.id from docdet d left join item i on i.id = d.id_item where d.ID_DOC is null and d.i2 is null
Re: FB 2.0, индексы по integer (is null)
Да, наша бага в оптимизаторе. Исправил, спасибо. -- Дмитрий Еманов
Re: FB 2.0, индексы по integer (is null)
> Исправил, спасибо. Тк... я смотрю SP1 на подходе ... "процесс пошел", что неможет не радовать P.S. я ж говорил... только скажите РЕЛИЗ! ...:) P.P.S. уезжаю в отпуск... только поэтому отложил переход на FB2.
Re: FB 2.0, индексы по integer (is null)
Plotnikov Y wrote: А тема вот в чем - скажите плиз, когда (примерно, очень примерно) можно будет рассчитывать на альфы 2.1? До НГ. -- Дмитрий Еманов
Re: FB 2.0, индексы по integer (is null)
"Plotnikov Y" ... > > А, понял ;))) > под ёлку положите ; Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :) -- Хорсун Влад PS Что мешает не ждать милостей от ёлки, а самому собрать ?
Re: FB 2.0, индексы по integer (is null)
> Да, наша бага в оптимизаторе. Исправил, спасибо. Блин, мы уже во все филиалы закачали сборку 12748 :) Коваленко Дмитрий.
Re: FB 2.0, индексы по integer (is null)
Kovalenko Dmitry wrote: Да, наша бага в оптимизаторе. Исправил, спасибо. Блин, мы уже во все филиалы закачали сборку 12748 :) Эта бага мелкая, редкая и не опасная. Вот другая (в соседней ветке) - опасная. Так что если мешаешь NULL-ы и пустые строки в одном индексированном поле и в WHERE разделяешь их - будут траблы. -- Дмитрий Еманов
Re: FB 2.0, индексы по integer (is null)
> >> Да, наша бага в оптимизаторе. Исправил, спасибо. > > > > Блин, мы уже во все филиалы закачали > > сборку 12748 :) > > Эта бага мелкая, редкая и не опасная. Вот другая (в соседней ветке) - > опасная. Так что если мешаешь NULL-ы и пустые строки в одном > индексированном поле и в WHERE разделяешь их - будут траблы. Так. На некоторое время надо завязать с чтением этого форума. :) Коваленко Дмитрий.
Re: FB 2.0, индексы по integer (is null)
Андрей Могильный wrote: Дим, а исправления таких ошибок выльются в конце концов в какое-то обновление для FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих думаю пропадет желание переходить на FB2.0. Ай, посчитай x в 1.0.x и в 1.5.x и успокойся. Статистика шепчет, что бог троицу любит :) -- Regards. Ded.
Re: FB 2.0, индексы по integer (is null)
"Андрей Могильный" ... > > Дим, > > а исправления таких ошибок выльются в конце концов в какое-то обновление для > FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих > думаю пропадет желание переходить на FB2.0. Будет 2.0.1 Конечно намного раньше, чем 2.1 -- Хорсун Влад
Re: FB 2.0, индексы по integer (is null)
Андрей Могильный wrote: а исправления таких ошибок выльются в конце концов в какое-то обновление для FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих думаю пропадет желание переходить на FB2.0. Перед 2.0.1 постараемся еще организовать снапшоты ветки 2.0.x. Т.к. там правятся только очевидные баги, оные можно будет считать условно-стабильными. Дмитрий
Re: FB 2.0, индексы по integer (is null)
Андрей Могильный wrote: Во! Это я и хотел услышать! Ладно, ребят, плывем дальше. :) http://tracker.firebirdsql.org/browse/CORE?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- Дмитрий Еманов
Re: FB 2.0, индексы по integer (is null)
Horsun Vlad пишет: Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :) Т.е. вместо отмечания НГ будете ударными темпами готовить релиз 2.1? ;-) -- С уважением, Андрей Еремин.
Re: FB 2.0, индексы по integer (is null)
Hello, Andrei! You wrote on Thu, 30 Nov 2006 16:24:49 +0300: >> Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :) AY> Т.е. вместо отмечания НГ будете ударными темпами готовить релиз 2.1? ;-) Ну не релиз же ж! Речь только об альфе шла! Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixtntobru
Re: fb 1.5.3 ss error during savepoint backout и падающие индексы
"Gene Feudorov" ... > > Hello, Dmitri Kuzmenko! > You wrote on Tue, 25 Apr 2006 16:54:15 +0400: > > DK> им если пользоваться, то для отчетов, чтобы "побыстрее выполнилось". > > а отчего для работы то нельзя!? Если очень хочется - то можно ;) Но - не нужно. Единственное видимое мне применение - если таблица будет заведомо пересоздана, или вся БД уйдёт на свалку (обрезание ненужных данных перед архивированием + б\р, например), но это - 0.001% применений, имхо > мусор у нас ночами свипом собираетса! А зачем его копить выше крыши ? > DK> И все. Понятно, что если мусор не собирается, с индексами и будет > DK> такая байда. > > дык ладно б тока с индексами. > заваливается одна и та же таблица (слава богу аналитическая - генерируемая) > никакие менды не помогают, селект из неё и бэкап не делается > только дроп её спасает. > она единственная заполняется в триггере вот таким макаром: > > execute statement 'insert into Analysis_Item_Store.' > execute statement 'update Analysis_Item_Store ' > > я эти экзекуты не использую, но коллега мой зачем то такое написал. > не может быть в этом бодяга? Я так и не понял об чём речь :( Могу тупить :) -- Хорсун Влад
Re: fb 1.5.3 ss error during savepoint backout и падающие индексы
Привет! а скорость работы пользователей? Влад, у нас 300 коннектов активно долбят в рабочее время! и включение сборки мусора хорошо отображается на процессоре а одно из основных требований заказчика - "главное, штоп не тормозило!" :-) А что у вас за железо? И какая конфигурация FB - буферов сколько, firebird.conf какой? Можно в приват. C уважением, Алексей
Re: fb 1.5.3 ss error during savepoint backout и падающие индексы
"Gene Feudorov" ... > а скорость работы пользователей? > Влад, у нас 300 коннектов активно долбят в рабочее время! > и включение сборки мусора хорошо отображается на процессоре > а одно из основных требований заказчика - "главное, штоп не тормозило!" :-) Не верю (с) Сборка мусора - это, грубо говоря, ещё один параллельно всем работающий SELECT, причём с низким приоритетом. На фоне активных 300 коннектов его просто невозможно увидеть. А процессор и должен быть загружен, если есть чем :) > >> мусор у нас ночами свипом собираетса! > HV> А зачем его копить выше крыши ? > > да чо уш выше крыши то? > ну накопится сотня-другая метров за сутки, > а свип его за пятнацать минут вычистит ночью, > когда нагрузка минимальна. Сам себе противоречишь : если свип вычищает суточный мусор за 15 мин, то такую нагрузку, размазанную в течение дня, тем более увидеть не реально. Боюсь у тебя какие-то другие тормоза... Может ты всё-таки о свипе говорил ? -- Хорсун Влад
Re: fb 1.5.3 ss error during savepoint backout и падающие индексы
Прямо ужасы какие-то на нось глядя :( У нас тоже(?) сборка мусора отключена на уровне базы данных - по ночам работает свип. Он правда не "15 минут" работает, а (как правило) полтора-два часа. Разрыв в транзакциях за смену достигает 170-200 тыс. И мы эту базу еще и апгрейдим иногда ... Мамаа . !!! Наверное надо завтра с утра втихоря обратно включить эти несчастные 2, от греха подальше ... Коваленко Дмитрий.
Re: fb 1.5.3 ss error during savepoint backout и падающие индексы
"Kovalenko Dmitry" ... > Прямо ужасы какие-то на нось глядя :( > > У нас тоже(?) сборка мусора отключена на > уровне базы данных - по ночам работает > свип. Он правда не "15 минут" работает, а > (как правило) полтора-два часа. > > Разрыв в транзакциях за смену > достигает 170-200 тыс. > > И мы эту базу еще и апгрейдим иногда ... > > Мамаа . !!! > > Наверное надо завтра с утра втихоря > обратно включить эти несчастные 2, от > греха подальше ... Отставить ужасы. Ты говоришь о sweep_interval, а Gene - о isc_dpb_no_garbage_collect у всех своих коннектов. У тебя сборка мусора _работает_ -- Хорсун Влад
Re: fb 1.5.3 ss error during savepoint backout и падающие индексы
>> У нас тоже(?) сборка мусора отключена на >> уровне базы данных >Ну хоть ты не путай сборку мусора со свипом :-) А, ну да. Чего это я ? :) Дим, когда целый день - с 8 до 20:00 - продолбенишься с программированием, начнешь путать что угодно :) Мысль о том что это все таки разные вещи была, но потом я вспомнил что в одном единственном месте у меня таки используется "isc_dpb_no_garbage_collect" - для заливки наших VBS-ов в базу данных. Ну, после этого, и накрыло. Коваленко Дмитрий.
