Re: backup restore
В процессе backup restore триггеры и процедуры перекомпилируются? :) А если текст стереть?
Re: backup restore
Привет! Чего-то меня переклинило. В процессе backup restore триггеры и процедуры перекомпилируются? Нет. Они же компилируются и так и хранятся. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: backup restore
Нет. Они же компилируются и так и хранятся. Так и выходит. С одной стороны плохо, с другой стороны хорошо. А если переход с версии на версию сервера и есть несовместимость. Тогда что? Не востановиться? Дмитрий
Re[2]: backup restore
Привет! Так и выходит. С одной стороны плохо, с другой стороны хорошо. А если переход с версии на версию сервера и есть несовместимость. Тогда что? Не востановиться? Получишь Invalid BLR at offset. При переходе обычно тестируют :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Re[2]: backup restore
В письме от Fri, 15 Apr 2011 18:29:30 +0400, Sergey Mereutsa gebele...@gmail.com сообщал: Получишь Invalid BLR at offset. При переходе обычно тестируют :) казалось бы в таком случае сервер бы мог и попытаться перекомпилировать... хуже уже не будет :-) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: backup restore
Доброго времени суток! Alexey Voytsehovich пишет: но не устраняет проблем с фрагментацией исходного бд файла. А вообще почему он возникает? У Вас же только вставка и удаление? Вставка сама по себе вроде бы не должна приводить к сильной фрагментации. А вот удаление, и последующая сборка мусора, вместе со вставкой - вполне может. Но по идее, DROP TABLE просто помечает скопом соответствующие страницы как свободные, а это довольно шустрая операция, и сильной фрагментации быть не должно. Пусть разработчики меня поправят, если что. обычная хранимка имхо :) Нет, простой хранимкой не получится - тогда будут зависимости и удалить таблицу Вы никак не сможете. Я предлагал следующий вариант - есть таблицы DATA_1 , DATA_2 и т.д., содержащие сами данные и есть таблица, хранящая информацию о периодах. Соответственно, чтобы сделать выборку по временному диапазону, нужно обратиться к таблице периодов, определить какие таблицы будут использоваться и сформировать запрос. Если делать это на стороне сервера, то потребуется ES+EB. Чтобы удалить таблицу, сначала нужно снести запись о ней в таблице периодов. Правда, делать это придется в монопольном режиме, но простой составит несколько секунд (если все обращения к таблице периодов будут через ХП, то можно попробовать обернуть операции чтения/записи через mutex - на ibase.ru вроде были соответствующие UDF). В общем, эмуляция сегментирования средствами FB :) -- С уважением, Евгений
Re[2]: backup restore
Hello Alexey, Thursday, September 11, 2008, 8:02:31 PM, you wrote: AV вооот AV за это спасибо. почитаю про сегментирование. Есть ли такое (или аналог в mssql)? Посмотри PostgreSQL, лицензия BSD по моему. тама тоже есть партиции дока 5.9.3. Managing Partitions ... The simplest option for removing old data is simply to drop the partition that is no longer necessary: DROP TABLE measurement_y2006m02; This can very quickly delete millions of records because it doesn't have to individually delete every record. Читал давеча про него, прикалывался :) вобщем пригни тудысь http://postgresmen.ru/news/view/111 Тема Дня: Hецензуpное выpажение лица. До не скорой встречи в аду, Maxmailto:[EMAIL PROTECTED]
Re: backup restore
Кузнецов Евгений wrote: В общем, эмуляция сегментирования средствами FB :) до меня только недавно дошло что можно все это реализовать внешними таблицами. тогда уж точно 100% сегментирование и отсутствие фрагментации. надо только потестировать на скорость вставки\выборки. насколько потеряю
Re: backup restore
Кузнецов Евгений wrote: Доброго времени суток! Alexey Voytsehovich пишет: но не устраняет проблем с фрагментацией исходного бд файла. А вообще почему он возникает? У Вас же только вставка и удаление? Вставка сама по себе вроде бы не должна приводить к сильной фрагментации. А вот удаление, и последующая сборка мусора, вместе со вставкой - вполне может. так вот таким образом и работаю. день вставляю - потом ночью удаляю.
Re: backup restore
Max Rezanov wrote: Hello Alexey, Thursday, September 11, 2008, 8:02:31 PM, you wrote: AV вооот AV за это спасибо. почитаю про сегментирование. Есть ли такое (или аналог в mssql)? Посмотри PostgreSQL, лицензия BSD по моему. тама тоже есть партиции дока 5.9.3. Managing Partitions The simplest option for removing old data is simply to drop the partition that is no longer necessary: DROP TABLE measurement_y2006m02; This can very quickly delete millions of records because it doesn't have to individually delete every record. спасибо :)
Re: backup restore
Alexey Voytsehovich пишет: до меня только недавно дошло что можно все это реализовать внешними таблицами. тогда уж точно 100% сегментирование и отсутствие фрагментации. Можно, вот только как с ними работать при отсутствии индексов? Или уже реализовали поддержку? -- С уважением, Евгений
Re: backup restore
Качановский Дмитрий wrote: да - система круглосуточная. на данный момент приняли решение реализовывать такой вариант ... если ты не против я еще один вопрос задам: выборки из этой таблицы - насколько сложными они будут?? эту будут сугубо выборки по времени (+датчик+параметр) для того что просмотреть значения датчиков в заданный момент времени? в основном такие. (там обычно строится тренд за какое то время назад (не очень большое)) или будут запросы для определния, например, среднего или максимального значения за период, например, сутки? такого вроде нет. и какая переодичность этих запросов ожидается - 1-2 в неделю (только в случае аварии) или людям надо постоянно просматривать эту информацию? пару раз в день (максимум) в случае аварии - постоянное построение тренда. еще я понял, что надо будет строить графики по множеству значений одного датчика. за какой период планируется строить эти графики - неделя/день/на выбор пользователя? обычно все пляшет вокруг пары часов, в худших случаях - до дней.
Re: backup restore
Чтобы удалить таблицу, сначала нужно снести запись о ней в таблице периодов. Правда, делать это придется в монопольном режиме, но простой составит несколько секунд (если все обращения к таблице периодов будут через ХП, то можно попробовать обернуть операции чтения/записи через mutex - на ibase.ru вроде были соответствующие UDF). Еще раз подумал - mutex тут не в кассу. Проблема - что делать со snapshot-транзакциями, ведь они будут продолжать видеть запись в таблице периодов до своего завершения. Попробовать стартовать consistency-транзакцию на таблицу DATA и в случае успеха удалить саму таблицу, а возможные ошибки в процедуре чтения обработать на клиенте или в ХП? Надо поразмыслить. -- С уважением, Евгений
Re: backup restore
могу показаться назойливым, но, как я уже писал (да и не только я), твоя главная проблема - операции с диском, соответственно надо думать в двух направлениях 1. ускорить дисковую подсистему (тут уже по этому поводу рекомендации давали) - это даст определеный выйгрышь, но полностью не решит задачу за тебя 2. уменьшить количество дисковых операций и разнести их более равномерно во времени (если у тебя 24х7 система, то абсолютно нелогично делать ночные плановые операции по сборке мусора). при таком подходе к разработке самым лучшим решением для тебя будет использовать плоские файлы - таким образом достигнешь максимальной скорости (за счет предельного уменьшения количества дисковых операций). Разбей, например, все данные по часам (насколько я помню тебе надо только 7 дней), у тебя получится 168 файлов и накапливай там инфу по револьверному принципу. Файлы добавляются с каждым часом, перевалил через неделю - удалил соответствующий файл, потом следующий и т.д. Как только приходит запрос просмотреть состояние датчиков, выбираешь интересующий час, закачиваешь клиенту файл, там парсишь (данные можно хранить в максимально подготовленном к этой операции виде) и строишь тренд. Это будет самый быстрый способ. Но если все-таки хочешь в работе использовать СУБД, то необходимо понять и принять, что СУБД, для управления данными, выполняет ряд дополнительных операций, объем которых зачастую превышает объем полезных операций. Соответственно базу необходимо проектировать, а не просто создать одну единственную таблицу и надеятся, что сервер все сделает за тебя. Например, на вопрос за какой промежуток времени могут понадобиться данные ты пишешь обычно все пляшет вокруг пары часов, в худших случаях - до дней. Ты прикидывал сколько записей тебе придется прокачать на клиента? Миллионы... сколько времени на это уйдет товарищь будет не рад что задал такой вопрос какой же там тренд за сутки?. Куда логичнее иметь в базе таблице где бы данные были уже подготовлены к просмотру с необходимой точностью. Условно говоря усредненные значения по датчикам за сутки, 2 часа, 15 минут (т.е. 3 таблицы). Соответственно отдавть клиенту подготовленные данные с такой же точностью. Если надо оценить общую ситуацию за неделю - значит берем данные из таблицы по дням, если за последние пару часов - из таблицы с 15-и минутным интервалом, просмотреть сотояние датчиков - исходные данные. Заполнение таблиц с подготовленными отчетами можно конечно поставить по расписанию, если периоды анализа небольшие - это в принципе допустимо, но если ты попытаешься это сделать за сутки, можешь всерьез и надолго поставить систему раком. Мое мнение в этом плане - лучше заполнять эти таблицы он-лайн, т.е. так только появляется новая информация по датчику, сразу же идет пересчет (update) в таблицах с отчетами. Это конечно же добавит версий, но поскольку операции во ремении более равномерно распределяются, серверу будет куда проще все это проглотить (и не поперхнуться). Далее - нафига тебе 3 индекса, да еще подозреваю составных, на грязные данные? Оставь только ОДИН по времени, все операции, которые ты выполняешь над этой таблицей полностью покрываются этим индексом. Во-первых, ты уменьшаешь количество структур и, соответственно, объем данных на диске. За счет этого (не могу утверждать однозначно, но ориентируясь на свои эксперименты с большими объемами) ты сократишь на 60% время удаления устаревших данных. Во-вторых, если необходим диапазонный поиск (аля between), то ФБ с индексами работает далеко не так идеально как хотелось бы, особенно с составными. Если парметр времени в индексе не один (т.е. индекс составной) то для диапазонной выборки такой индекс фактически не работает совсем. В-третьих, время (я так понимаю timestamp) - это составной параметр, можно попробовать (вот здесь надо будет эксперементировать) добавить еще одно поле в таблицу - номер минуты, например от 2008 года. Интежера будет достаточно на тысячи лет вперед. По нему и строить индекс, а поиск проводить по этому полю с уточнением по времени. Насчет разделения данных по таблицам здесь уже много писали, повторяться не буду. Только вот не помню почему была отвергнута идея хранить данные по каждому датчику+параметру в отдельной таблице (таблиц конечно же много будет, но работать с ними может даже и проще). и последнее. Опять же уже писалось, но повторюсь. Если данные заходят с с такой интенсивностью и равномерно в течение суток, то и выходить они оттуда должны соответственно. Вполне логично, что пытаясь удалить накопившуюся инфу за сутки ты ставишь сервер в такую позу из которой он не может выйти очень долго. Удаляй данные пропорционально их добавлению. Например если задачу очистки поставить раз в 10 мин. - серверу будет надо удалить 170.000 записей (исходя из твоих исходных данных). Серверу будет куда проще пережевать такой объем и через 10 мин. быть готовым к повторению этой операции (естественно с учетом, что он продолжает
Re: backup restore
Качановский Дмитрий wrote: могу показаться назойливым, но, как я уже писал (да и не только я), твоя главная проблема - операции с диском, соответственно надо думать в двух направлениях 1. ускорить дисковую подсистему (тут уже по этому поводу рекомендации давали) - это даст определеный выйгрышь, но полностью не решит задачу за тебя 2. уменьшить количество дисковых операций и разнести их более равномерно во времени (если у тебя 24х7 система, то абсолютно нелогично делать ночные плановые операции по сборке мусора). спасибо. реально интересное письмо заставившее задуматься. после решения проблем - отпишусь сюда как решили.
Re: backup restore
On Sep 11, 3:31 pm, Oleg Matveyev [EMAIL PROTECTED] wrote: видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям отпиши сюда о результатах. интересно Да, да, было бы очень полезно. Единственное но - я, к примеру, почти все тонкие места в Firebird в таких задачах знаю, и как обойти знаю, а вот в остальных серверах - хрен их знает, может там своих backup- restore, сборок мусора и прочих тонкостей хватает. Так что правильное сравнение аккуратно сделать - та еще задача.
Re: backup restore
ëÕÚÎÅÃÏ× å×ÇÅÎÉÊ wrote: ÷ ÏÂÝÅÍ, ÜÍÕÌÑÃÉÑ ÓÅÇÍÅÎÔÉÒÏ×ÁÎÉÑ ÓÒÅÄÓÔ×ÁÍÉ FB :) ÄÏ ÍÅÎÑ ÔÏÌØËÏ ÎÅÄÁ×ÎÏ ÄÏÛÌÏ ÞÔÏ ÍÏÖÎÏ ×ÓÅ ÜÔÏ ÒÅÁÌÉÚÏ×ÁÔØ ×ÎÅÛÎÉÍÉ ÔÁÂÌÉÃÁÍÉ. ÔÏÇÄÁ ÕÖ ÔÏÞÎÏ 100% ÓÅÇÍÅÎÔÉÒÏ×ÁÎÉÅ É ÏÔÓÕÔÓÔ×ÉÅ ÆÒÁÇÍÅÎÔÁÃÉÉ. ÎÁÄÏ ÔÏÌØËÏ ÐÏÔÅÓÔÉÒÏ×ÁÔØ ÎÁ ÓËÏÒÏÓÔØ ×ÓÔÁ×ËÉ\×ÙÂÏÒËÉ. ÎÁÓËÏÌØËÏ ÐÏÔÅÒÑÀ úÄÒÁÓÔØÔÅ, ÔÏÌØËÏ ÎÅÄÁ×ÎÏ ÄÏ ÄÏÛÌÏ. ôÅÂÅ ÍÅÓÑà ÎÁÚÁÄ ÓËÁÚÁÌÉ, Ñ × ÔÏÍ ÞÉÓÌÅ - ÈÒÁÎÉ ÐÏÄÒÏÂÎÙÅ ÄÁÎÎÙÅ ×Ï ×ÎÅÛÎÉÈ ÆÁÊÌÁÈ, (ÍÏÖÎÏ ×Ï ×ÎÅÛÎÉÈ ÔÁÂÌÉÃÁÈ / ÍÏÖÎÏ × ÒÏÄÎÏÍ ÆÏÒÍÁÔÅ, ËÁË ÐÏÓÔÕÐÁÀÔ Ó ÄÁÔÞÉËÏ×) É ÄÏÓÔÁ×ÁÊ ÉÈ ÔÏÌØËÏ ËÏÇÄÁ ÏÎÑ ÐÏÎÁÄÏÂÑÔÓÑ, Á × âä ÈÒÁÎÉ ÓÕÍÍÉÒÏ×ÁÎÎÙÅ ÕÓÒÅÄÎÅÎÎÙÅ ÐÏ ÐÅÒÉÏÄÁÍ × ÎÁÐÒ. 20ÓÅË. é ÉÈ ÎÅ ÎÁÄÏ ÕÄÁÌÑÔØ ÇÏÄ ÍÉÎÉÍÕÍ. ðÏ ÁÎÁÌÏÇÉÉ Ó ËÁÒÔÉÎËÁÍÉ. èÒÁÎÉÛØ ÔÏÌØËÏ ÐÕÔØ. óÏÈÒÁÎÑÅÛØ/ÞÉÔÁÅÛØ ÞÅÒÅÚ èð.
Re: backup restore
Alexey Voytsehovich [EMAIL PROTECTED] ñîîáùèë/ñîîáùèëà â íîâîñòÿõ ñëåäóþùåå: news:[EMAIL PROTECTED] Êà÷àíîâñêèé Äìèòðèé wrote: ìîãó ïîêàçàòüñÿ íàçîéëèâûì, íî, êàê ÿ óæå ïèñàë (äà è íå òîëüêî ÿ), òâîÿ ãëàâíàÿ ïðîáëåìà - îïåðàöèè ñ äèñêîì, ñîîòâåòñòâåííî íàäî äóìàòü â äâóõ íàïðàâëåíèÿõ 1. óñêîðèòü äèñêîâóþ ïîäñèñòåìó (òóò óæå ïî ýòîìó ïîâîäó ðåêîìåíäàöèè äàâàëè) - ýòî äàñò îïðåäåëåíûé âûéãðûøü, íî ïîëíîñòüþ íå ðåøèò çàäà÷ó çà òåáÿ 2. óìåíüøèòü êîëè÷åñòâî äèñêîâûõ îïåðàöèé è ðàçíåñòè èõ áîëåå ðàâíîìåðíî âî âðåìåíè (åñëè ó òåáÿ 24õ7 ñèñòåìà, òî àáñîëþòíî íåëîãè÷íî äåëàòü íî÷íûå ïëàíîâûå îïåðàöèè ïî ñáîðêå ìóñîðà). ñïàñèáî. ðåàëüíî èíòåðåñíîå ïèñüìî çàñòàâèâøåå çàäóìàòüñÿ. ïîñëå ðåøåíèÿ ïðîáëåì - îòïèøóñü ñþäà êàê ðåøèëè. Êñòàòè Îáðàòè âíèìàíèå íà ñîâåò ïî èíäåêñó. Åñëè ó òåáÿ åñòü èíäåêñ ïî âðåìÿ+ID_óñðîéñòâà, òî îí ïîëíîñòüþ çàäåéñòâóåòñÿ òîëüêî ïðè çàïðîñå WHERE âðåìÿ=?X and ID_óñðîéñòâà=?Y! Ïðè ëþáîì çàïðîñå çà ïåðèîä ÷àñü ID_óñðîéñòâà íå çàäåéñòâóåòñÿ ÍÈÊÎÃÄÀ è áåñïîëåçíà.
Re: backup restore
у меня есть подозрение, что там толпа индексов на этой маленькой табличке. 3. она занимает 90% размера и практически 100% обращений идет к ней. и еще один вопрос: если я правильно понял система которую вы разрабатывает 24х7 т.е. нет перерыва на ночь, когда можно было бы выполнять обслуживающие операции??
Re: backup restore
Качановский Дмитрий wrote: у меня есть подозрение, что там толпа индексов на этой маленькой табличке. 3. она занимает 90% размера и практически 100% обращений идет к ней. и еще один вопрос: если я правильно понял система которую вы разрабатывает 24х7 т.е. нет перерыва на ночь, когда можно было бы выполнять обслуживающие операции?? да - система круглосуточная. на данный момент приняли решение реализовывать такой вариант 1. в течение недели накапливаем данные, и удаляем, но мусор не собираем. 2. в субботу ночью сервер начинает накапливать данные в памяти (реализовано), доступ к бд прекращается (насчет этого еще не все ясно, будем экспериментировать) 3. запускается бакуп 4. проверяем чтобы не было ошибок 5. запускаем рестор 6. переименовываем старую в отресторенную 7. сервер сбрасывает накопленные данные в бд ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд.
Re[2]: backup restore
Hello Alexey, Thursday, September 11, 2008, 2:35:23 PM, you wrote: AV да - система круглосуточная. на данный момент приняли решение реализовывать AV такой вариант AV 1. в течение недели накапливаем данные, и удаляем, но мусор не собираем. AV 2. в субботу ночью сервер начинает накапливать данные в памяти (реализовано), AV доступ к бд прекращается (насчет этого еще не все ясно, будем экспериментировать) AV 3. запускается бакуп AV 4. проверяем чтобы не было ошибок AV 5. запускаем рестор AV 6. переименовываем старую в отресторенную AV 7. сервер сбрасывает накопленные данные в бд AV ЗюЫю AV рук-во поставило в план задач тестирование необходимого нам функционала AV (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих AV видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям AV (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о AV смене субд. А если без удалений совсем Считай всего то 400 гектар в год. На новый год заводите новую базу и пересекаете ее на неделю со старым годом. Тема Дня: Тот, кто хpапит, всегда засыпает пеpвым. До не скорой встречи в аду, Maxmailto:[EMAIL PROTECTED]
Re: backup restore
âèäàõ ñóáä - ìññêë, ïîñòãðå, îðàêë. Åñëè îäíà èç íèõ óäîâëåòâîðèò òðåáîâàíèÿì îòïèøè ñþäà î ðåçóëüòàòàõ. èíòåðåñíî
Re: backup restore
Доброго времени суток! On 11 сент, 14:35, Alexey Voytsehovich wrote: ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд. Вероятно, что на блокировочнике Вам будет полегче. По поводу существующей системы на FB - я бы попробовал хранить данные за каждый день в отдельных таблицах. В этом случае чистка данных - это просто удаление таблицы без негативных последствий в виде сборки мусора. Правда, усложняются все запросы, но это решаемо через ES/EB. -- С уважением, Евгений
Re: backup restore
Oleg Matveyev wrote: видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям отпиши сюда о результатах. интересно ок
Re: backup restore
Кузнецов Евгений wrote: Доброго времени суток! On 11 сент, 14:35, Alexey Voytsehovich wrote: ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд. Вероятно, что на блокировочнике Вам будет полегче. По поводу существующей системы на FB - я бы попробовал хранить данные за каждый день в отдельных таблицах. В этом случае чистка данных - это просто удаление таблицы без негативных последствий в виде сборки мусора. но не устраняет проблем с фрагментацией исходного бд файла. Правда, усложняются все запросы, но это решаемо через ES/EB. обычная хранимка имхо :)
Re: backup restore
Dmitry Voroshin wrote: Alexey Voytsehovich ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене суб А почему нет MySQL? Нетранзакционный движек дролжен на такой задаче показать наибольшую скорость. может посмотрим и на него. но с ним не все понятно в лицензионной политике к сожалению.
Re: backup restore
Храпко Виктор wrote: Alexey Voytsehovich[EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] ЗюЫю рук-во поставило в план задач тестирование необходимого нам функционала (примерно 1 гиг в сутки поступающих данных, раз в сутки очистка) на следующих видах субд - мсскл, постгре, оракл. Если одна из них удовлетворит требованиям (без утомительного бакуп\ресторе) - будет принято решение (процентов на 90) о смене субд. Вообще такая бяка реализуется на ОРАКЛЕ. Поставь оракл и прочитай Тома Кайта Книжку. Там написано Как создавать сегментированную таблицу и по мере необходимости просто добавлять и удалять сегменты таблицу. Удаление сегмента это секунды вооот за это спасибо. почитаю про сегментирование. Есть ли такое (или аналог в mssql)?
Re: backup restore
в mssql тоже есть сегментирование таблиц
backup restore
Всем доброго дня. Не подскажете способ как на 2.5 версии сервера сделать операцию бакуп ресторе, с заменой рабочей бд на отресторенную (конечно если все ок) - и чтобы за все время бакупарестора - никто не мог подключиться к бд? Заранее спасибо.
Re: backup restore
îÅ ÐÏÄÓËÁÖÅÔÅ ÓÐÏÓÏ ËÁË ÎÁ 2.5 ×ÅÒÓÉÉ ÓÅÒ×ÅÒÁ ÓÄÅÌÁÔØ ÏÐÅÒÁÃÉÀ ÂÁËÕÐ ÒÅÓÔÏÒÅ, Ó ÚÁÍÅÎÏÊ ÒÁÂÏÞÅÊ ÂÄ ÎÁ ÏÔÒÅÓÔÏÒÅÎÎÕÀ (ËÏÎÅÞÎÏ ÅÓÌÉ ×ÓÅ ÏË) - É ÞÔÏÂÙ ÚÁ ×ÓÅ ×ÒÅÍÑ ÂÁËÕÐÁÒÅÓÔÏÒÁ - ÎÉËÔÏ ÎÅ ÍÏÇ ÐÏÄËÌÀÞÉÔØÓÑ Ë ÂÄ? úÁ ×ÒÅÍÑ ÂÜËÁÐÁ ÌÀÂÏÊ ÐÏ ÏÐÒÅÄÅÌÅÎÉÀ ÓÍÏÖÅÔ ÚÁÊÔÉ × ÂÁÚÕ, Ô.Ë. ÓÁÍ ÐÒÏÃÅÓÓ ÂÅËÁÐÁ - ÒÑÄÏ×ÏÅ ÐÏÄËÌÀÞÅÎÉÅ äÌÑ ÍÏÎÏÐÏÌØÎÏÓÔÉ ÓÔÏÉÔ ÐÅÒÅ×ÅÓÔÉ ÂÁÚÕ × ÛÁÔÄÁÕÎ. úÁ ×ÒÅÍÑ ÒÅÓÔÏÒÁ, ÏÐÑÔØ ÖÅ ÐÏ ÏÐÒÅÄÅÌÅÎÉÀ, ÎÉËÔÏ ÎÅ ÓÍÏÖÅÔ ÚÁÊÔÉ × ÎÅÏÔÒÅÓÔÏÒÅÎÎÕÀ ÂÁÚÕ, ÎÁÞÉÎÁÑ ÔÏ ÌÉ Ó 2.0, ÔÏ ÌÉ Ó 2.1 p.s. ÚÁ ÒÅÓÔÏÒ ÐÏ×ÅÒÈ ÂÏÅ×ÏÊ ÂÁÚÙ ÂØÀÔ ÎÏÇÁÍÉ
Re: backup restore
Не подскажете способ как на 2.5 версии сервера сделать операцию бакуп ресторе, с заменой рабочей бд на отресторенную (конечно если все ок) - и чтобы за все время бакупарестора - никто не мог подключиться к бд? Погасить сервер Файл переименовать Поднять сервер Заниматься делами Переименовать назад
Re: backup restore
á ÍÎÅ ×ÏÔ ÅÝÅ ÉÎÔÅÒÅÓÎÏ - ÎÅÕÖÔÏ ÎÁ 2.5 ÅÓÔØ ÓÙÍÓÌ × ÏÐÅÒÁÃÉÉ backup/restore îÅÔ, Ñ ËÏÎÅÞÎÏ ÐÏÎÉÍÁÀ, ÉÎÄÅËÓÙ ×ÙÓÔÒÏÑÔÓÑ ÐÒÏÓÔÏ ÉÄÅÁÌØÎÏ... ÄÁ ÅÝÅ ÎÅËÏÔÏÒÙÅ ×ÅÝÉ... îÏ Ñ ×ÏÔ Ó ÕÖÁÓÏÍ ×ÓÐÏÍÎÉÁÀ ×ÒÅÍÅÎÁ, ËÏÇÄÁ ÎÁÄÏ ÂÙÌÏ ÄÅÌÁÔØ BR ÒÁÚ × ÍÅÓÑÃ, ÏÔËÌÀÞÁÑ ×ÓÅÈ ÎÁ ÞÁÓ-Ä×Á. é ÍÏÌÉÔÓÑ, ÞÔÏ ÂÙ ÎÉËÔÏ ÉÚ ÒÁÚÒÁÂÏÔÞÉËÏ× ÎÅ ÎÁÐÁÒÔÁÞÉÌ × ÂÁÚÅ (ÎÅ×ÏÓÓÔÁÎÏ×ÉÍÙÊ ÂÁËÁÐ)
Re: backup restore
ðÏÇÁÓÉÔØ ÓÅÒ×ÅÒ ÔÏÌØËÏ × SuperServer
Re: backup restore
Погасить сервер только в SuperServer Покилять всех :-)
Re: backup restore
Oleg Matveyev wrote: только в SuperServer И в SuperClassic :-) -- Дмитрий Еманов
Re: backup restore
Oleg Matveyev wrote: Но я вот с ужасом вспомниаю времена, когда надо было делать BR раз в месяц, отключая всех на час-два. И когда такое было? --
Re: backup restore
Slava Ekimov wrote: +Выдернуть сетевой шнур. Погасить сервер Файл переименовать Поднять сервер Заниматься делами Переименовать назад --
Re: backup restore
Oleg Matveyev wrote: А мне вот еще интересно - неужто на 2.5 есть сымсл в операции backup/restore Нет, я конечно понимаю, индексы выстроятся просто идеально... да еще некоторые вещи... таблица на 107 миллионов записей, каждый день 12 лимонов удаляем, столько же добавляем, через некоторое время дикие тормоза на сборе статистики и удалении. :( а так как причину не нашли, да особо и не знаем как ее найти, решили делать b\r
Re: backup restore
Alexey Voytsehovich wrote: таблица на 107 миллионов записей, каждый день 12 лимонов удаляем, столько же добавляем, через некоторое время дикие тормоза на сборе статистики и удалении. :( А при отключенных юзерах тормоза тоже имеют место? ЗЫ. Какой размер базы, если хорошенько заархивировать? :-) Я мог бы выкачать и взглянуть... -- Дмитрий Еманов
Re: backup restore
вХМЗБЮЕЧ уЕТЗЕК wrote: Не подскажете способ как на 2.5 версии сервера сделать операцию бакуп ресторе, с заменой рабочей бд на отресторенную (конечно если все ок) - и чтобы за все время бакупарестора - никто не мог подключиться к бд? За время бэкапа любой по определению сможет зайти в базу, т.к. сам процесс бекапа - рядовое подключение Для монопольности стоит перевести базу в шатдаун. то есть gfix.exe -attach? что будут делать уже висящие в бд пользователи? (сервер -классик) За время рестора, опять же по определению, никто не сможет зайти в неотресторенную базу, начиная то ли с 2.0, то ли с 2.1 спасибо. но ресторить буду в соседний алиас, потом переименую файлы. p.s. за рестор поверх боевой базы бьют ногами учту ;)
Re: backup restore
Dmitry Yemanov wrote: Alexey Voytsehovich wrote: таблица на 107 миллионов записей, каждый день 12 лимонов удаляем, столько же добавляем, через некоторое время дикие тормоза на сборе статистики и удалении. :( А при отключенных юзерах тормоза тоже имеют место? вот информация снятая запросами mon$attacments mon$statements ## OPC ## MON$ATTACHMENT_ID MON$SERVER_PID MON$STATE MON$ATTACHMENT_NAME MON$USER MON$ROLE MON$REMOTE_PROTOCOL MON$REMOTE_ADDRESS MON$REMOTE_PID MON$CHARACTER_SET_ID MON$TIMESTAMP MON$GARBAGE_COLLECTION MON$REMOTE_PROCESS MON$STAT_ID = == = === === === === === == = == === 122471 4892 1 opc SYSDBA NONE TCPv4 127.0.0.1 4004 0 2008-09-10 08:00:09.5460 1 c:\Program Files\Firebird\Firebird_2_5\bin\isql.exe 2 122458 3956 1 opc SYSDBA NONE TCPv4 127.0.0.1 3024 0 2008-09-09 21:00:03.8430 1 C:\Program Files\OPCServer\demoserver1_0.exe 8 MON$STATEMENT_ID MON$ATTACHMENT_ID MON$TRANSACTION_ID MON$STATE MON$TIMESTAMP MON$SQL_TEXT MON$STAT_ID = == = = = 51224712652436 1 2008-09-10 08:00:09.90600:16 == MON$SQL_TEXT: select * from MON$ATTACHMENTS == 101224582652367 1 2008-09-09 21:00:46.28100:2 11 == MON$SQL_TEXT: delete from MomData where ARDTimeStamp (current_date - 7) == вот последняя статистика на momdata (которую смогли посчитать, состояние на 06-09-08 01-19 MOMDATA (154) Primary pointer page: 200, Index root page: 201 Average record length: 25.36, total records: 105694679 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 434068, data page slots: 917632, average fill: 63% Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 0 60 - 79% = 434067 80 - 99% = 0 Index IDX_MOMDATA1_NEW1 (0) Depth: 3, leaf buckets: 72877, nodes: 105730152 Average data length: 0.13, total dup: 98687506, max dup: 86963 Fill distribution: 0 - 19% = 329 20 - 39% = 40 40 - 59% = 62317 60 - 79% = 7875 80 - 99% = 2316 Index IDX_MOMDATA2_NEW1 (1) Depth: 3, leaf buckets: 104131, nodes: 144318020 Average data length: 0.91, total dup: 98687204, max dup: 87015 Fill distribution: 0 - 19% = 794 20 - 39% = 218 40 - 59% = 77941 60 - 79% = 7260 80 - 99% = 17918 Index IDX_MOMDATA4_NEW1 (2) Depth: 3, leaf buckets: 82926, nodes: 105818657 Average data length: 3.00, total dup: 178400, max dup: 21754 Fill distribution: 0 - 19% = 2316 20 - 39% = 603 40 - 59% = 32118 60 - 79% = 1134 80 - 99% = 46755 вот заголовок бд (на то же время) Database D:\Program Files\Firebird\Firebird_2_1\opc.ib Database header page information: Flags 0 Checksum12345 Generation 2234021 Page size 16384 ODS version 11.2 Oldest transaction 2217472 Oldest active
Re: backup restore
Hello, Alexey! Alexey Voytsehovich wrote: таблица на 107 миллионов записей, каждый день 12 лимонов удаляем, столько же добавляем, хреново. сколько индексов на таблице, и какая у них селективность? через некоторое время дикие тормоза на сборе статистики и удалении. :( а так как причину не нашли, да особо и не знаем как ее найти, решили делать b\r ну а рестор сколько проходит этих 24 гиг? p.s. комментарий к твоему следующему посту: Ты несколько странен. размер базы указываешь в байтах, когда при гигабайтных размерах на байты и даже мегабайты покласть. инфу пуляешь прямо в письме (а не в файле), отчего она становится плохо читабельной. Используешь альфу ФБ, когда альфа незастрахована от изменений в ОДС, таких, что раньше при аналогичных случаях вроде даже приходилось базу целиком из скрипта пересоздавать, и т.д. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: backup restore
Dmitri Kuzmenko wrote: Hello, Alexey! Alexey Voytsehovich wrote: таблица на 107 миллионов записей, каждый день 12 лимонов удаляем, столько же добавляем, хреново. сколько индексов на таблице, и какая у них селективность? как получить инфу о селективности? кол-во индексов выложил в письме от 13:33 через некоторое время дикие тормоза на сборе статистики и удалении. :( а так как причину не нашли, да особо и не знаем как ее найти, решили делать b\r ну а рестор сколько проходит этих 24 гиг? 2 часа максимум (там размер бакупа 5 гиг) p.s. комментарий к твоему следующему посту: Ты несколько странен. размер базы указываешь в байтах, когда при гигабайтных размерах на байты и даже мегабайты покласть. это стандартный вывод команды dir (ходит мне такая инфа каждый час :) ) инфу пуляешь прямо в письме (а не в файле), отчего она становится плохо :( вот тут согласен. не очень привык в news писать с аттачами. читабельной. Используешь альфу ФБ, когда альфа незастрахована от изменений в ОДС, таких, что раньше при аналогичных случаях вроде даже приходилось базу целиком из скрипта пересоздавать, та мне тут разработчики советовали на нее переходить, в частности изза суперклассик технологии (у нас несколько одновременно и напряженно работающих бд на одном сервере) + по условиям одной из задач нужны кроссбд-шные запросы на стороне сервера.
Re: backup restore
сервер 4-х головый, 4 гига памяти, винты скорость до 90 мб\с, две сетевые карты в разные подсети, все операции идут на Localhost:opc (алиас орс существует) Таблица более 6-ти гиг. С 4-мя гигами ОЗУ оно обречено убивать винты. Независимо от кол-ва голов. -- Хорсун Влад
Re: backup restore
Vlad Khorsun wrote: сервер 4-х головый, 4 гига памяти, винты скорость до 90 мб\с, две сетевые карты в разные подсети, все операции идут на Localhost:opc (алиас орс существует) Таблица более 6-ти гиг. С 4-мя гигами ОЗУ оно обречено убивать винты. Независимо от кол-ва голов. то есть уменьшить менее 4 гиг (достаточно сделать удаление в монопольном со сборкой мусора) и будет все ок? и если мне надо хранить данных обьемом на 6 гиг то просто нарезать на таблицы?
Re: backup restore
Alexey Voytsehovich ... Vlad Khorsun wrote: сервер 4-х головый, 4 гига памяти, винты скорость до 90 мб\с, две сетевые карты в разные подсети, все операции идут на Localhost:opc (алиас орс существует) Таблица более 6-ти гиг. С 4-мя гигами ОЗУ оно обречено убивать винты. Независимо от кол-ва голов. то есть уменьшить менее 4 гиг (достаточно сделать удаление в монопольном со сборкой мусора) и будет все ок? и если мне надо хранить данных обьемом на 6 гиг то просто нарезать на таблицы? Конечно нет. Есть мнение (не очень проверенное), что виндовый файловый кеш вообще плохо работает с большими файлами (больше 4-8 гиг). Были даже такие баги, как невозможность скопировать такой файл (в w2k лично наблюдал, вроде в сп4 исправили, не помню деталей). Я бы переходил на x64 и доставлял памяти сколько влезет в слоты. Она нынче дешёвая. Ну и - рэйд 5 или 10 тут совсем не помешает. Ибо тебе нужна скорость винтов не вообще, а random read\write (заявленные тобой 90 мб\с это sequential) -- Хорсун Влад
Re: backup restore
Vlad Khorsun wrote: Конечно нет. Есть мнение (не очень проверенное), что виндовый файловый кеш вообще плохо работает с большими файлами (больше 4-8 гиг). Были даже такие баги, как невозможность скопировать такой файл (в w2k лично наблюдал, вроде в сп4 исправили, не помню деталей). Влад, что тогда посоветуешь в организации бд если необходимо все таки хранить такой обьем? нарезать по таблицам, а таблицы раскидать по физическим файлам (бд)? или еще чтото? Я бы переходил на x64 и доставлял памяти сколько влезет в слоты. Она нынче дешёвая. Ну и - рэйд 5 или 10 тут совсем не помешает. Ибо тебе нужна скорость винтов не вообще, а random read\write (заявленные тобой 90 мб\с это sequential) эту инфу постараюсь донести рук-ву и заказчикам. но... одно оч печально - если на текущей конфигурации компа ФБ не сможет вытяивать такие обьемы, скорее всего мне скажут сделать тесты на oracle, postgre, mysql - и если ктото из них вытянет такое - то уйдем туда :( чего не хотелось бы - ибо интересно работать с ФБ. хоть и не понятно иногда :)
Re: backup restore
Alexey Voytsehovich ... Vlad Khorsun wrote: Конечно нет. Есть мнение (не очень проверенное), что виндовый файловый кеш вообще плохо работает с большими файлами (больше 4-8 гиг). Были даже такие баги, как невозможность скопировать такой файл (в w2k лично наблюдал, вроде в сп4 исправили, не помню деталей). Влад, что тогда посоветуешь в организации бд если необходимо все таки хранить такой обьем? нарезать по таблицам, а таблицы раскидать по физическим файлам (бд)? или еще чтото? Хранить - скока угодно. Читать все 24 гига постоянно - оно точно нужно ? Я бы переходил на x64 и доставлял памяти сколько влезет в слоты. Она нынче дешёвая. Ну и - рэйд 5 или 10 тут совсем не помешает. Ибо тебе нужна скорость винтов не вообще, а random read\write (заявленные тобой 90 мб\с это sequential) эту инфу постараюсь донести рук-ву и заказчикам. но... одно оч печально - если на текущей конфигурации компа ФБ не сможет вытяивать такие обьемы, скорее всего мне скажут сделать тесты на oracle, postgre, mysql - и если ктото из них вытянет такое - то уйдем туда :( чего не хотелось бы - ибо интересно работать с ФБ. хоть и не понятно иногда :) А что именно он не вытягивает ? Сбор статистики ? Она, кстати, читается непосредственно из файла БД, в обход страничного кеша FB. Отсюда могут быть такие (гигантские) числа по статистике чтения. -- Хорсун Влад
Re: backup restore
Vlad Khorsun wrote: сервер 4-х головый, 4 гига памяти, винты скорость до 90 мб\с, две сетевые карты в разные подсети, все операции идут на Localhost:opc (алиас орс существует) Таблица более 6-ти гиг. С 4-мя гигами ОЗУ оно обречено убивать винты. Независимо от кол-ва голов. но, статистика что я тебе прислал - тогда все работало нормально (и размер этой таблицы не мог измениться сильно), перестало работать позже. при чем причина точно не в ПО работающем с сервером и не с сервером ФБ (потому что его не обновляли) значит либо чтото с самой бд (битая) либо чтото с внешним миром изменилось. Можно ли определить почему ФБ медленно собирает статистику? может выпустите какой то билд gstat с включенными отадочными сообщениями? я его запущу и итог вам вышлю?
Re: backup restore
Vlad Khorsun wrote: Alexey Voytsehovich ... Vlad Khorsun wrote: Конечно нет. Есть мнение (не очень проверенное), что виндовый файловый кеш вообще плохо работает с большими файлами (больше 4-8 гиг). Были даже такие баги, как невозможность скопировать такой файл (в w2k лично наблюдал, вроде в сп4 исправили, не помню деталей). Влад, что тогда посоветуешь в организации бд если необходимо все таки хранить такой обьем? нарезать по таблицам, а таблицы раскидать по физическим файлам (бд)? или еще чтото? Хранить - скока угодно. Читать все 24 гига постоянно - оно точно нужно ? так оно постоянно и не читается в общем то ... и идут постоянные вставки в эту таблицу (с периодом в 10 сек) иногда делаем выборки по индексу CREATE INDEX IDX_MOMDATA4_NEW1 ON MOMDATA (DEVID,TYPEDEVICE,CHANNELID,ARDTIMESTAMP); раз в сутки удаляем 12 миллионов записей. (столько за день приходит) то есть держим колво на уровне данных за 7 дней. и раз в сутки собираем мусор и делаем бакуп (статистику делаю для себя чтобы следать за бд хоть немного) Я бы переходил на x64 и доставлял памяти сколько влезет в слоты. Она нынче дешёвая. Ну и - рэйд 5 или 10 тут совсем не помешает. Ибо тебе нужна скорость винтов не вообще, а random read\write (заявленные тобой 90 мб\с это sequential) эту инфу постараюсь донести рук-ву и заказчикам. но... одно оч печально - если на текущей конфигурации компа ФБ не сможет вытяивать такие обьемы, скорее всего мне скажут сделать тесты на oracle, postgre, mysql - и если ктото из них вытянет такое - то уйдем туда :( чего не хотелось бы - ибо интересно работать с ФБ. хоть и не понятно иногда :) А что именно он не вытягивает ? Сбор статистики ? ну вот в последнее время стала оч сильно статистика тормозить и удаление записей. Она, кстати, читается непосредственно из файла БД, в обход страничного кеша FB. Отсюда могут быть такие (гигантские) числа по статистике чтения. понятно. но плохо что она за 7-8 часов не завершается. так же как и удаление. я ж и прошу, может сделаешь какой то тестовый билд или какую либо программу? я ее запущу и вывод отправлю тебе? чтобы к примеру ты мне конкретно сказал что тормозит винт, или процессор, или промахи мимо кеша постоянные, или сетка падает. а я уже буду думать как это устранить или обойти?
Re: backup restore
до 24.04.2007 у меня такое было на Ya. вот чесслово - Яфил был во многом хорош, и БР был быстрее. И вроде я делал тоже самое - свип каждую ночь, лично следил за ОАТ... но более 40 дней без БР - ну никак не получалось. падала производительность в аккурат к началу месяца - к отчетности. с 24.04.2007, после перехода на FB2.0, БР не делали ни разу. но объемы не такие конечно, - база 8,5Гб, ram 4Гб вставки/удаления есть в одной таблице, но не так много - около 10 тыс. записей в день.
Re: backup restore
Hello, Alexey! Alexey Voytsehovich wrote: хреново. сколько индексов на таблице, и какая у них селективность? как получить инфу о селективности? кол-во индексов выложил в письме от 13:33 IBAnalyst есть? читай хелп к нему, там все написано. ну а рестор сколько проходит этих 24 гиг? 2 часа максимум (там размер бакупа 5 гиг) гм. бэкап 5 гиг, а рабочая база 24? я бы посмотрел, сколько там пустых страниц, но есть подозрение на какие-нибудь охрененно фрагментированные структуры. это стандартный вывод команды dir (ходит мне такая инфа каждый час :) ) и настолько тебе лениво было его упростить? инфу пуляешь прямо в письме (а не в файле), отчего она становится плохо :( вот тут согласен. не очень привык в news писать с аттачами. привыкай. та мне тут разработчики советовали на нее переходить, в частности изза суперклассик технологии (у нас несколько одновременно и напряженно работающих бд на одном сервере) + по условиям одной из задач нужны кроссбд-шные запросы на стороне сервера. понятно. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: backup restore
2 часа максимум (там размер бакупа 5 гиг) гм. бэкап 5 гиг, а рабочая база 24? я бы посмотрел, сколько там пустых страниц, но есть подозрение на какие-нибудь охрененно фрагментированные структуры. у меня есть подозрение, что там толпа индексов на этой маленькой табличке. и вот еще вопрос: в обсуждении все время фигурирует только эта таблица, складывается впечатление что кроме нее ничего больше в базе нет, это у меня ошибочное впечатление? -- С уважением Качановский Дмитрий ООО КОШТпроект
Re: backup restore
Качановский Дмитрий wrote: 2 часа максимум (там размер бакупа 5 гиг) гм. бэкап 5 гиг, а рабочая база 24? я бы посмотрел, сколько там пустых страниц, но есть подозрение на какие-нибудь охрененно фрагментированные структуры. у меня есть подозрение, что там толпа индексов на этой маленькой табличке. 3. и вот еще вопрос: в обсуждении все время фигурирует только эта таблица, складывается впечатление что кроме нее ничего больше в базе нет, это у меня ошибочное впечатление? она занимает 90% размера и практически 100% обращений идет к ней.
Re: Проблема с правами после backup/restore.`
dada sasa [EMAIL PROTECTED] wrote: Сервак, на котором создавалась база, то ли 1.5, то ли 1.5.1 - к сожалению, точно не скажу. Сейчас работает под 1.5.2 (WI-V6.3.2 4731)), где, собственно, и есть проблемы с backup/restore. При возможности проверь на FB2. Есть подозрение, что там отработает нормально. -- Дмитрий Еманов
Re: Проблема с правами после backup/restore.`
Пардон, пардон! Самое главное не сообщил! Сервак, на котором создавалась база, то ли 1.5, то ли 1.5.1 - к сожалению, точно не скажу. Сейчас работает под 1.5.2 (WI-V6.3.2 4731)), где, собственно, и есть проблемы с backup/restore. Похоже, что они впервые и появились после перехода на 1.5.2
