Khorsun Vlad hv...@optima.com.ua
сообщил/сообщила в новостях следующее: news:iuklug$bcf$1...@dough.gmane.org...
Внешние соединения кешироваться будут, но точно не в 2.5.1
В 3.0 будут? Этот вопрос для меня очень животрепещущ.
Voroshin Dmitry wrote ...
Khorsun Vlad сообщил/сообщила в новостях ...
Внешние соединения кешироваться будут, но точно не в 2.5.1
В 3.0 будут? Этот вопрос для меня очень животрепещущ.
Это есть в todo, но не с самым высоким приоритетом.
--
Хорсун Влад
Vlad Khorsun hv...@optima.com.ua
сообщил/сообщила в новостях следующее: news:ivmbdn$ktc$1...@dough.gmane.org...
Voroshin Dmitry wrote ...
Khorsun Vlad сообщил/сообщила в новостях ...
Внешние соединения кешироваться будут, но точно не в 2.5.1
В 3.0 будут? Этот вопрос для меня очень
Михаил Викторович wrote ...
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали составные
Михаил Викторович wrote:
Я написал свое мнение о том, что человек прав, придя к идее архива.
Это плохая идея.
Если уж делать ахрив, то создавая копию базы на на какой то момент времени.
В одном из проектов мы использовали архивные таблицы в той же базе. Конечно
время бакапа растет, но пока
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает
сливание битовых карт индексов на сверхбольшых
Михаил Викторович wrote:
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
Тогда хотелось бы услышать о выявленных узких местах в вашей ситуации.
На самом деле есть
Михаил Викторович wrote:
Кто же их упомнит. Несколько десятков определенных вручную планов.
Ручные ещё не значит хорошие.
Вставка как вставка обычная где то в три-четыре таблицы, что про нее еще
можно сказать я не знаю.
Индексов штук 8-10 в каждой таблице. При активной работе 400-650
Михаил Викторович ...
Тест интересный, но я в нем не нашел теста на вставку большие таблицы когда
уже седаны индексы, падение будет существенным,
Прям предсказатель :-D
по хорошему тоже надо бы
протестировать, будет время займусь. Мой опыт говорит о том что убирая не
нужные индексы можно
Vlad Khorsun wrote:
Да. Но это не связано с размером таблицы. Можно и на маленькой
таблице получить
большие тормоза при вставке - просто создав десятки индексов с длинными
ключами.
Вопрос то в рависимости от размера таблицы. Ведь она в любом случае
должна быть логарифмической.
PS
Так тут дело не во вставке а в общем торможении сервера (ЦПУ, винт,
память) при большой нагрузке.
Это верно.
Если это суперсервер, то естественно большое количество кривых селектов
O да Вы оказывается экстрасенс.
Прям предсказатель :-D
А то :)
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали
06.07.2011 18:59, Михаил Викторович пишет:
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим
Подскажите в IB была такая фигня, если в индексе низкая селективность,
то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку
в
конце, для борьбы с этим делали составные ключи добавляя в них
06.07.2011 19:43, Михаил Викторович пишет:
Можно задать вопрос по другому. Опишу ситуацию есть таблица из 1 записей
в ней есть индекс по полю у которого всего два значения(приход/расход). В IB
было замечания что одинаковые значения ключа сортируются в порядке вставки в
базу для этого IB
A K wrote:
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора.
Это ничего почти не даст. Если запросы используют только данные за
последнее время, то размер таблиц фактически не влияет за
Может вполне хватит следующих действий и при существующей структуре:
* Более производительное оборудование специально выделенное под работу
СУБД - быстрый дисковый массив, много оперативной памяти, 64битный
Firebird;
если бы мы писали на оракле или на 1С, тогда да, стандартный подход
придти к
а так, имеем таких клиентов, которые элементарно жмутся на технике и
тяжко им что-то втолковать.
Значит остальное попробовать. Был случай когда добавление двух индексов
уменьшило время выполнения операции с 30 минут до 20 секунд. Наличие
долгих снэпшот транзакций может сильно нагружать
.
-Original Message-
From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On
Behalf Of Евгений Виноградный
Sent: Tuesday, July 05, 2011 9:37 PM
To: ru-firebird@googlegroups.com
Subject: Re: EXECUTE STATEMENT к другой базе в рамках установленного
коннекта
а так, имеем таких клиентов
On 05.07.2011 22:00, Михаил Викторович wrote:
В итоге все равно будет перегрузка по производительности. Решение с
архивом
верное. Теперь когда проектирую новые системы сразу предусматриваю
архивирование.
Тем не менее для более дельных рекомендаций по данному случаю мало
информации:
*
Тем не менее для более дельных рекомендаций ...
А зачем мне Ваши рекомендации? Разве их я спрашивал?
Я написал свое мнение о том, что человек прав, придя к идее архива. На счет
реализации на триггерах и использования передачи в другую базу возможно вам
видней, такой вариант пока не использовал и
On 01.07.2011 23:55, A K wrote:
Транзакций существенно меньше чем CRUD операций как правило.
я понимаю, что в общем случае их будет меньше. Но, например, накопил я
в логе десять изменений в разных таблицах. Идет комит транзакции.
Мне все равно придется выполнить десять EXECUTE STATEMENT к
А вот с синхронной репликацией на уровне триггеров есть реальный шанс
получить большие проблемы (по моему скромному мнению это путь в никуда).
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние
A K ...
Реальная ситуация. Большая база на большом предприятии. Работает медленно.
Что именно медленно ? Запросы или обслуживание ?
Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора.
И с чего бы оно стало быстрее ? Кривые запросы, читающие кучу не
нужной
On 04.07.2011 19:48, A K wrote:
Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора. Изменения в оперативной БД, должны попадать
на архивную.
Возьмите/купите одну из готовых систем репликации под Firebird - будет
дешевле и быстрее, чем изобретать велосипед.
Может
А по моему лучше в триггерах накапливать изменения, а репликацию делать
в отдельном потоке.
Добрый день!
Возможность выполнять EXECUTE STATEMENT на другой базе
позволяет легко реализовать надежную схему односторонней
онлайн репликации.
Но, вся засада в том, что коннект к базе открывается
каждый раз при выполнении оператора. Мы собрали у себя тестовый пример.
Изменения без репликации
A K wrote ...
Добрый день!
Возможность выполнять EXECUTE STATEMENT на другой базе
позволяет легко реализовать надежную схему односторонней
онлайн репликации.
Но, вся засада в том, что коннект к базе открывается
каждый раз при выполнении оператора. Мы собрали у себя тестовый пример.
Изменения
On 01.07.2011 19:47, A K wrote:
Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту
тр-ции.
А что это изменит? Все равно каждый EXECUTE STATEMENT будет
открывать-закрывать подключение к БД. Только что подвисать будет не
каждая операция, а комит транзакции.
Транзакций
Транзакций существенно меньше чем CRUD операций как правило.
я понимаю, что в общем случае их будет меньше. Но, например, накопил я
в логе десять изменений в разных таблицах. Идет комит транзакции.
Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней
базе, причем каждый
30 matches
Mail list logo
