Re: OFF: Ded! С днем Рождения!
Запоздало присоединяюсь. С Днем Рождения! Главное здоровья, отдыхать почаще, ну и не забывать про эмерджентность бытия сконцентированную в данном виртуальном сообществе! С уважением, Алексей Ковязин On 22 сент, 14:28, Ded [EMAIL PROTECTED] wrote:
фрагментация бд
Всем доброго дня. Наверное всех уже достал, но вопрос все равно пока еще не решен. Есть БД, в ней таблица величиной около 7 гигабайт. Внутри хранятся данные обратным сроком на 7 дней назад. Такой формат обусловлен ТЗ, изменить ничего не получится - уже пробовали. В течение дня в базу добавляется данных примерно на 1 гигабайт, и тот же самый 1 Гб удаляется ночью (все данные старше 7 дней) соответственно примерно за неделю фрагментация получается просто дикая, что подтверждается длительным временем сборки мусора в бд. возможно ли каким то образом работать с ФБ (внешние таблицы, хитрые хранимки, данные не удалять, а апгрейдить) чтобы избежать данной фрагментации, а, соответственно, серьезного замедления обслуживающих бд операций. Заранее спасибо. ЗюЫю точные данные по времени операций в различных конфигурациях (отключенные индексы, пересозданные, после b\r операции) подготавливаются. Этот пост для затравки темы и сборки идей что еще проверить.
Re: ������������ ��
åÓÌÉ 7 ÄÎÅÊ ÚÁÛÉÔÏ × ôú, ÔÏ ÚÁÛÉÔØ × âä 7 ÔÁÂÌÉà - ÐÏ ÏÄÎÏÊ ÎÁ ÄÅÎØ :-) ÉÍÅÎÁ ÔÁÂÌÉÃÁÍ ÄÁÔØ ÆÉËÓÉÒÏ×ÁÎÎÙÅ, ÎÁËÒÕÔÉÔØ ÎÁ ÎÉÈ ×ØÀÈ... ÒÁÚ × ÄÅÎØ ÏÄÎÕ ÔÁÂÌÉÃÕ ÐÅÒÅÓÏÚÄÁ×ÁÔØ.
Re: ЖТБЗНЕОФБГЙС ВД
On 23.09.2008 14:37, Oleg Matveyev wrote: Если 7 дней зашито в ТЗ, то зашить в БД 7 таблиц - по одной на день :-) имена таблицам дать фиксированные, накрутить на них вьюх... раз в день одну таблицу пересоздавать. то есть алгоритм таков создали 7 внешних таблиц создали view имитирующий таблицу (сборку из 7 внешних) когда надо удалить одну из таблиц (стоп а нафиг ее удалять? может просто из нее данные удалить)? удалили view пересоздали внешнюю таблицу создали view в нашем коде предусмотреть момент чтоб когда не находил таблицу, не падал. Сразу вопрос. есть хранимка, которая пользуется данными из этой view, соответственно пересоздаваться все будет оч трудно? ща попробую удалить из внешней данные. что получится.
Re: ������������ ��
òî åñòü àëãîðèòì òàêîâ äà, êàê-òî ñëîæíî ïîëó÷àåòñÿ :-) ñîçäàëè 7 âíåøíèõ òàáëèö õìì... ÿ âîîáùå-òî íå èìåë ââèäó âíåøíèå òàáëèöû. õîòÿ ñî âíåøíèìè òàáëèöàìè âàðèàíò èíòåðåñíûé. óæå óïîìèíàëîñü. Îñòàíîâèòü FB, è ôàéë óäàëèòü, è ñîçäàòü íîâûé, ïóñòîé. íî òîãäà ïðèéäåòñÿ îáõîäèòñÿ áåç èíäåêñîâ...
Re: ЖТБЗНЕОФБГЙС ВД
On 23.09.2008 14:59, Oleg Matveyev wrote: то есть алгоритм таков да, как-то сложно получается :-) а шо делать создали 7 внешних таблиц хмм... я вообще-то не имел ввиду внешние таблицы. а другие ведь все равно будут делать фрагментацию? хотя со внешними таблицами вариант интересный. уже упоминалось. Остановить FB, и файл удалить, и создать новый, пустой. можно и без остановки ФБ. удаляется таблица на лету. но тогда прийдется обходится без индексов... помучаюсь пока без них. проверю на скорости. вот тогда не знаю, как поступать с view которая может ссылатся на удаляемую внешнюю таблицу. пересоздавать всё?
Re: ЖТБЗНЕОФБГЙС ВД
On 23.09.2008 15:20, Alexey Voytsehovich wrote: хотя со внешними таблицами вариант интересный. уже упоминалось. Остановить FB, и файл удалить, и создать новый, пустой. можно и без остановки ФБ. удаляется таблица на лету. поторопился. удалятся то удаляется. логически. но данные все равно остаются. точно придется еще и физический файл грохать. в общем буду читать и искать.
Re: ������������ ��
ïîòîðîïèëñÿ. óäàëÿòñÿ òî óäàëÿåòñÿ. ëîãè÷åñêè. íî äàííûå âñå ðàâíî îñòàþòñÿ. òî÷íî ïðèäåòñÿ åùå è ôèçè÷åñêèé ôàéë ãðîõàòü. â îáùåì áóäó ÷èòàòü è èñêàòü. êàê ðàç â äàííîì ñëó÷àåå òåáå ïðîùå òîëüêî ôàéë óäàëèòü. à òàáëèöó â áä íå òðîãàòü. òîëüêî ïðîöåññ FB áóäåò ôàéë óäåðæèâàòü - ïðèäåòñÿ åãî îñòàíàâëèâàòü. âîçìîæíî ýòî â òâîåé ñèñòåìå 24*7 - õîòü íà ïàðó ìèíóò?
Re: ЖТБЗНЕОФБГЙС ВД
On 23.09.2008 15:28, Oleg Matveyev wrote: поторопился. удалятся то удаляется. логически. но данные все равно остаются. точно придется еще и физический файл грохать. в общем буду читать и искать. как раз в данном случаее тебе проще только файл удалить. а таблицу в бд не трогать. только процесс FB будет файл удерживать - придется его останавливать. возможно это в твоей системе 24*7 - хоть на пару минут? оч. нежелательно. желающих общатся с бд много. и не всех можно проконтролировать. может что разработчики посоветуют? а то рук-во услышало про сегментирование в взрослых субд, теперь компосирует мне мозги.
Re: ЖТБЗНЕОФБГЙС ВД
Oleg Matveyev ... поторопился. удалятся то удаляется. логически. но данные все равно остаются. точно придется еще и физический файл грохать. в общем буду читать и искать. как раз в данном случаее тебе проще только файл удалить. а таблицу в бд не трогать. только процесс FB будет файл удерживать - придется его останавливать. возможно это в твоей системе 24*7 - хоть на пару минут? 2.1 отпускает файл как только все запросы к нему освобождены. Т.е. если нет процедур\триггеров, обращающихся ко внешним таблицам, то останавливать FB не нужно. -- Хорсун Влад
Re: ЖТБЗНЕОФБГЙС ВД
On 23.09.2008 15:50, Vlad Khorsun wrote: 2.1 отпускает файл как только все запросы к нему освобождены. у меня даже 2.5 :) Т.е. если нет процедур\триггеров, обращающихся ко внешним таблицам, то останавливать FB не нужно. может посоветуешь как мне тогда решить проблему с view (в которой будут объединены данные из 7 внешних таблиц, по таблице на день)? то есть я буду создавать к примеру 7 внешних таблиц, в них будут данные. когда наступает 8-й день мне необходимо таблицу в которой данные на минус седьмой день удалить, а в новую начать писать, и чтобы после (или перед) удалением минус седьмой таблицы view уже работала с новым набором таблиц. на view будут ссылаться триггера. поэтому просто её удалить не получится, а можно ли будет изменить?
Re: ЖТБЗНЕОФБГЙС ВД
Alexey Voytsehovich ... может посоветуешь как мне тогда решить проблему Пока PS (из первого поста) не опишешь - никаких вразумительных советов быть просто не может. -- Хорсун Влад
Re: ЖТБЗНЕОФБГЙС ВД
у меня даже 2.5 :) Запомним это. может посоветуешь как мне тогда решить проблему с view (в которой будут объединены данные из 7 внешних таблиц, по таблице на день)? то есть я буду создавать к примеру 7 внешних таблиц, в них будут данные. когда наступает 8-й день мне необходимо таблицу в которой данные на минус седьмой день удалить, а в новую начать писать, и чтобы после (или перед) удалением минус седьмой таблицы view уже работала с новым набором таблиц. на view будут ссылаться триггера. поэтому просто её удалить не получится, а можно ли будет изменить? 1) Тут кто-то обещал возможность CREATE VIEW из PROCEDURE. Сам не проверял, но вроде должно. 2) В процедуре можно воспользоваться EXECUTE STATEMENT. В триггерах на VIEW - тоже. Идея в общем такая: семь баз по дням недели. Демон (LINUX) или сервайс (Windows), который эти самые базы создает и, соответственно, убивает уже ненужные. В базах - одна и та же таблица, а выборка - через CROSS- DATABASE запросы оператора EXECUTE STATEMENT. Фрагментация баз при этом уменьшается. -- З.Ы. Ну как, сдал я экзамен на прокто-стоматолога ? :)
unavailable database
Приветствую Вас, У клиента Firebird 1.5.3, я уже писал что я делаю репликацию (репликация своя) то на сетевом протоколе идут значительные задержки на локальном таких проблем нет, я использовал утилиту http://half-open.com/home_ru.htm и у меня проблема пропала но у клиента по его словам все-равно проблема. Т.к. тема как часто тут бывает переросла в стеб и флейм, я не нашел решения и решил перейти к локальному протоколу для репликации, но у клиента начала появляться ошибка unavailable database. Кстати когда-то давно такое было уже у пару клиентов почему и переделал репликацию на сетевой протокол, но я ни разу не смог отловить). Я у себя ставил на виртуалки и на 98 и XP и ни разу не смог повторить проблему. Вычитал в FAQ: * клиентская часть не поддерживает локальный протокол вообще такое бывает. Например, в Firebird 1.5.1 for Windows, Classic. * Скажите как это бывает? И почему бывает и не бывает? Т.е. я так понимаю либо клиентская часть не поддерживает локальный протокол либо поддерживает, а бывает это значит проблема не в этом, а в другом. Подскажите куда еще можно взглянуть почему клиент схватывает ошибку unavailable database, а я ну сколько уже не пробовал не могу повторить ошибку и все, может это от каких-то особенных настроек Windows, сети, возможно каике-то обновления Windows влияют, куда хоть копать? -- С Уважением, Дмитрий Котельников
Re: ������������ ��
наступает 8-й день мне необходимо таблицу в которой данные на минус седьмой день удалить, а в новую начать писать, и чтобы после (или перед) удалением минус идею пойми: ненадо DROP TABLE просто отсоединяются все, кто к таблицам внешним обращался (напрямую, или через вью/процедуры), _удаляешь_файл_ (сам, средствами ОС) в котором были данные таблицы (еще раз: DROP TABLE ненадо), при обращении во внешнюю таблицу увидишь, что она пустая. (вот только непомню, надо ли самому создать файл нулевой длины, или FB сам это сделает) А вообще конечно, ждем подробной инфо. Может геморрой не стоит свеч (с)
Re: ЖТБЗНЕОФБГЙС ВД
Доброго времени суток! PEAKTOP пишет: Идея в общем такая: семь баз по дням недели. Демон (LINUX) или сервайс (Windows), который эти самые базы создает и, соответственно, убивает уже ненужные. В базах - одна и та же таблица, а выборка - через CROSS- DATABASE запросы оператора EXECUTE STATEMENT. Фрагментация баз при этом уменьшается. Отлично, заодно и протестирует :) Действительно, 7 БД по дням недели + 1 управляющая БД, хранящая всю логику и сведения об остальных. А проблему блокировки старых данных можно решить через shutdown. Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в другом процессе? -- З.Ы. Ну как, сдал я экзамен на прокто-стоматолога ? :) 5, давайте зачетку :) -- С уважением, Евгений
Re: ЖТБЗНЕОФБГЙС ВД
Кузнецов Евгений пишет: Действительно, 7 БД по дням недели + 1 управляющая БД, хранящая всю логику и сведения об остальных. А проблему блокировки старых данных можно решить через shutdown. Тут, правда, некоторая проблема с алиасами возникает - либо их нужно динамически перезначать, либо от них вовсе отказаться и соединяться с полным путем к БД. -- С уважением, Евгений
Re: фрагментация бд
Alexey Voytsehovich wrote: В течение дня в базу добавляется данных примерно на 1 гигабайт, и тот же самый 1 Гб удаляется ночью (все данные старше 7 дней) Ночью - это типа майнтенанс тайм, без юзеров? Тогда отчего бы тут же не зашатдаунить базу и не свипануть? Не должно по-моему без залипших долгоиграющих транзакций долго идти, разумеется если нет индексов по булевским полям на этой таблице :) В гигах я как-то не считал, а мильёнчик записей из 10-миллионной ГБК грохнуть и перепровести мне не так чтоб частенько, но приходится, и без всякого дискомфорта, дольше 5 минут свип ни разу не летал. -- Regards. Ded.
Re: ЖТБЗНЕОФБГЙС ВД
Кузнецов Евгений ... Доброго времени суток! PEAKTOP пишет: Идея в общем такая: семь баз по дням недели. Демон (LINUX) или сервайс (Windows), который эти самые базы создает и, соответственно, убивает уже ненужные. В базах - одна и та же таблица, а выборка - через CROSS- DATABASE запросы оператора EXECUTE STATEMENT. Фрагментация баз при этом уменьшается. Отлично, заодно и протестирует :) Действительно, 7 БД по дням недели + 1 управляющая БД, хранящая всю логику и сведения об остальных. А проблему блокировки старых данных можно решить через shutdown. Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки данных. По идее старые БД не должны быть никогда и никем использованы. Время от времени удалять старые записи и, соответственно, удалять эти БД. А ещё лучше - не удалять БД, а делать в них RECREATE таблицам и использовать повторно. Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в другом процессе? На тот же хост с тем же портом - не будут. Если же использовать локальный коннект, то это будет embedded соединение. -- Хорсун Влад
Re: ЖТБЗНЕОФБГЙС ВД
Доброго времени суток! Vlad Khorsun пишет: Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки данных. Согласен. По идее старые БД не должны быть никогда и никем использованы. В принципе, да. Но когда я предлагал хранить ежедневные данные в отдельных таблицах, и циклически их удалять через DROP TABLE, возникла проблема - как обеспечить монопольный доступ к таблице, чтобы выдернуть ее из под носа у читающего клиента и гарантированно удалить? Вроде бы Shutdown для этого достаточно хорошо подходит. Время от времени удалять старые записи и, соответственно, удалять эти БД. А ещё лучше - не удалять БД, а делать в них RECREATE таблицам и использовать повторно. А будет ли разница - в одной БД хранить эти таблицы или в нескольких, если идет только вставка и удаление/пересоздание таблиц? Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в другом процессе? На тот же хост с тем же портом - не будут. Если же использовать локальный коннект, то это будет embedded соединение. Интересно, а почему было выбрано именно embedded, а не XNET? P.S. По предыдущему вопросу - после конференции стучаться? -- С уважением, Евгений
Re: ЖТБЗНЕОФБГЙС ВД
On 23.09.2008 20:20, Vlad Khorsun wrote: Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки данных. так и думал. а еще думал данные отдавать с хранимки по одной, константной бд, которая будет динамически строить и выполнять запросы к другим бд. По идее старые БД не должны быть никогда и никем использованы. Время от времени удалять старые записи и, соответственно, удалять эти БД. А ещё лучше - не удалять БД, а делать в них RECREATE таблицам и использовать повторно. а так как таблица будет одна на бд, то и фрагментации не будет. гуд.
Re: фрагментация бд
On 23.09.2008 19:35, Ded wrote: Alexey Voytsehovich wrote: В течение дня в базу добавляется данных примерно на 1 гигабайт, и тот же самый 1 Гб удаляется ночью (все данные старше 7 дней) Ночью - это типа майнтенанс тайм, без юзеров? Тогда отчего бы тут же не зашатдаунить базу и не свипануть? Не должно по-моему без залипших долгоиграющих транзакций долго идти, разумеется если нет индексов по булевским полям на этой таблице :) В гигах я как-то не считал, а опа. насчет индексов. при сборке мусора индекс пересчитывается на каждую операцию (или какой то блок), и, если индексы корявые, а данных много - то тормозить может не по детски?
Re: ЖТБЗНЕОФБГЙС ВД
Кузнецов Евгений ... Доброго времени суток! Vlad Khorsun пишет: Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки данных. Согласен. По идее старые БД не должны быть никогда и никем использованы. В принципе, да. Но когда я предлагал хранить ежедневные данные в отдельных таблицах, и циклически их удалять через DROP TABLE, возникла проблема - как обеспечить монопольный доступ к таблице, чтобы выдернуть ее из под носа у читающего клиента и гарантированно удалить? Вроде бы Shutdown для этого достаточно хорошо подходит. После добавления в таблицу с перечнем БД новой даты, новые запросы будут использовать свежие 7 дат (БД), а старые запросы со временем завершатся. В этот момент можно очищать старые (старую 8-ю) БД. Время от времени удалять старые записи и, соответственно, удалять эти БД. А ещё лучше - не удалять БД, а делать в них RECREATE таблицам и использовать повторно. А будет ли разница - в одной БД хранить эти таблицы или в нескольких, если идет только вставка и удаление/пересоздание таблиц? Несколько таблиц в одной внешней БД - те же фаберже, что и несколько таблиц в локальной БД ;) Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в другом процессе? На тот же хост с тем же портом - не будут. Если же использовать локальный коннект, то это будет embedded соединение. Интересно, а почему было выбрано именно embedded, а не XNET? Так само получилось ;) Если подумать, то окажется, что так и должно быть, сетевой слой тут лишний. P.S. По предыдущему вопросу - после конференции стучаться? Угу. Там есть проблема, но сходу она не разрешилась. Я сам постучу :) -- Хорсун Влад
Re: фрагментация бд
Alexey Voytsehovich ... опа. насчет индексов. при сборке мусора индекс пересчитывается на каждую операцию (или какой то блок), и, если индексы корявые, а данных много - то тормозить может не по детски? Сборка мусора удаляет сначала все ненужные версии записи, потом соотв. блобы и узлы индексов. Потом переходит к след. записи. Так что random IO там не слабый может быть. -- Хорсун Влад
Re: ЖТБЗНЕОФБГЙС ВД
Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в другом процессе? На тот же хост с тем же портом - не будут. Если же использовать локальный коннект, то это будет embedded соединение. А это embedded будет фактически подключением а-ля классик ? Ну в смысле, если два процесса классика сделают CROSS запрос (через embedded ) к другой базе - оно все корректно там будет разрулено? Коваленко Дмитрий. PS. Зацени мою воспитанность. Гыгы :-)
Re: фрагментация бд
On 23.09.2008 21:09, Vlad Khorsun wrote: Alexey Voytsehovich ... опа. насчет индексов. при сборке мусора индекс пересчитывается на каждую операцию (или какой то блок), и, если индексы корявые, а данных много - то тормозить может не по детски? Сборка мусора удаляет сначала все ненужные версии записи, потом соотв. блобы и узлы индексов. Потом переходит к след. записи. Так что random IO там не слабый может быть. попробую без индексов тоже самое
Re: ЖТБЗНЕОФБГЙС ВД
Kovalenko Dmitry ... Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в другом процессе? На тот же хост с тем же портом - не будут. Если же использовать локальный коннект, то это будет embedded соединение. А это embedded будет фактически подключением а-ля классик ? В SC\CS - да Ну в смысле, если два процесса классика сделают CROSS запрос (через embedded ) к другой базе - оно все корректно там будет разрулено? Качаем \ компилим, пробуем, докладуем ;) PS. Зацени мою воспитанность. Гыгы :-) usus, заценил :) -- Хорсун Влад
Re: ������������ ��
ìîæåò ïîñîâåòóåøü êàê ìíå òîãäà ðåøèòü ïðîáëåìó Ïîêà PS (èç ïåðâîãî ïîñòà) íå îïèøåøü - íèêàêèõ âðàçóìèòåëüíûõ ñîâåòîâ áûòü ïðîñòî íå ìîæåò. Çàäà÷à àññèíõðîííîãî ñíÿòèÿ äàííûõ ñ äàò÷èêîâ, è õðàíåíèÿ ýòèõ äàííûõ âîîîáùåì ïðèìèòèâíà, ñòî ðàç ïðîéäåíà, è åå ðåøàë çäåñü íàâåðíîå êàæäûé âòîðîé. Ñêîðî åå â øêîëàõ çàäàâàòü áóäóò íà óðîêàõ èíôîðìàòèêè ))). Àôòàð æå óïîðíî èãíîðèðóåò òî, ÷òî åìó ïèøóò óæå ìåñÿö. Âìåòî ýòîãî îí ïûòàåòñÿ ñîçäàòü ñàìîäâèæóùååñÿ óñòðîéñòâî î ñåìè íîãàõ ïðèäåëàâ èõ ê àâòîìîáèëþ, ïðè ýòîì íåïðåìåííûì óñëîâèåì ÒÇ ÿâëÿåòñÿ, ÷òî ïîñëå êàæäîãî øàãà êîñòûëü äîëæåí óäàëÿòüñÿ è çàìåíÿòüñÿ íîâûì.  ñâÿçè ñ çàñåêðå÷åííîñòüþ ÒÇ, è áîãàòûì âîîáðàæåíèåì îáùåñòâåííîñòè, êîñòûëè ïðåäñòàâëÿþòñÿ ðàçíûé äëèíû è êóäà èõ êðåïèòü - ìíîãî âàðèàíòîâ.  ÷èñëå ïðî÷åãî, ïðåäëàãàëîñü, íàïðèìåð, îñíàñòèòü êàæäóþ íîãó ñîáñòâåííûì äâèæêîì ñ ìèêðîïðîöåññîðîì, à â êàáèíó äîáàâèòü ñèñòåìó êðîññ-óïðàâëåíèÿ. Ïðè ýòîì, êàê íè ñòðàííî, îñíîâíàÿ ïðîáëåìà íàðèñîâàëàñü íå â ñëîæíîñòè óñòðîéñòâà, à â áûñòðîé çàìåíå êîñûëåé íå ïðåðûâàÿ äâèæåíèÿ. Âçãëÿäû â ñòîðîíó áîëåå ìîùíûõ äâèæêîâ íè ê ÷åìó íå ïðèâåëè, ò.ê. ÷åì ñëîæíåé äâèæîê òåì òðóäíåå áóäåò ìåíÿòü íîãè íà õîäó. Îê. ×òîáû ýòî íå áûëî ïóñòûì òðåïîì - òåïåðü ïî äåëó. Íàñêîëüêî ÿ ïîíÿë, òû ðåøèë îñòàíîâèòüñÿ íà âíåøíèõ òàáëèöàõ. 1) ïîêóïàåøü âèíò 500ãèã 2) ìîíòèðóåøü åãî êàê ïàïêó äëÿ õðàíåíèÿ âíåøíèõ òàáëèö 3) _äîïóñòèì_ êàæäàÿ òàáëèöà - 1 äåíü (aka: DATA_20080921, DATA_20080922, DATA_20080923) 4) !î÷åíü âàæíûé ïóíêò! ÍÅ ÍÀÄÎ ÍÈ×ÅÃÎ ÓÄÀËßÒÜ! ÍÅ ÍÀÄÎ ÍÈ×ÅÃÎ ÃÐÎÕÀÒÜ! 500ãèã òåáå õâàòèò ãîäà íà äâà ïðèìåðíî, ïîòîì çàìåíèøü íà âèíò 50 òåðàáàéò (ê òîìó âðåìåíè ýòî áóäåò ñòàíäàðòîì) Ñâåæèå äàííûå áóäóò â êåøå ÎÑ/ÁÄ. Ñòàðûå (ìåñÿ÷íîé äàâíîñòè) ìåøàòüñÿ íå áóäóò. 5) íå çàìîðà÷èâàåøüñÿ ñ âüþõàìè. 6) åäèíñòâåííàÿ ìàëåíüêàÿ ñëîæíîñü - ôîðìèðîâàíèå çàïðîñîâ íà êëèåíòå íàëåòó. Ò.å. çàïðîñ äàííûõ çà 3 äíÿ äîëæåí âûãëÿäåòü òèïà select * from DATA_20080921 d1 union all select * from DATA_20080922 d2 union all select * from DATA_20080923 d3 Ò.å. ïèøåøü ôóíêöèþ, function GetMySelectSQL(ATablePrefix: string; d1,d2: TDateTime): string; êîòîðàÿ, áóäåò ãåíåðèòü òàêîé çàïðîñ. Åñëè ïåðèîä ïåðåñåêàåò áîëüøå îäíîãî äíÿ - èç íåñêîëüêèõ òàáëèö ïî ìàñêå. Äîï ïàðàìåòðû. where, sort by, group by - ïî âêóñó. ÇÛ. ñàìà ÁÄ ìîæåò ëåæàòü íà ðàéäå íóæíîé ñòåïåíè íàäåæíîñòè, à äëÿ _ñûðûõ_ äàííûõ îñîáàÿ íàäåæíîñòü íå íóæíà - òû èõ âñå ðàâíî ñîáèðàëñÿ óäàëÿòü.
Re: Временные права
Наврал я про бэкап/рестор, проблема снова проявила себя после первого зависания сервера. Пробовал по всякому, revoke/grant, откатился на CS, на более раннюю версию сервера - все без толку. В общем, видать, фаза луны повлияла. Проблему окончательно решил пересозданием объектов, которые периодически становились недоступными (одна процедура и две таблицы). Всё же, хотелось бы узнать, как можно отследить в сети виновника торжества, если никаких глюков в работе клиентов не наблюдается, однако сервер периодически подвисает, а в логах только SERVER/process_packet: broken port, server exiting да INET/inet_error: read errno = 10054 ? Сетка небольшая, 14 компов, один свич...
ЙЦУКЕНТВОЮМАТЬ
Качаем \ компилим, пробуем, докладуем ;) Это ты мэнэ подколол. Коваленко Дмитрий. PS. ... но в код не заглядываем. Не толпимся, проходим, проходим на палубу FB 2.5, товарищи! PSS. Чо-то у меня gsec до сих пор падает. Вместе с сервером. Но я ему от 2.1.1 базу с паролями засунул и таки отчалил.
Re: ЖТБЗНЕОФБГЙС ВД
On 24.09.2008 2:33, Alexey Abramov wrote: может посоветуешь как мне тогда решить проблему Пока PS (из первого поста) не опишешь - никаких вразумительных советов быть просто не может. Задача ассинхронного снятия данных с датчиков, и хранения этих данных воообщем примитивна, сто раз пройдена, и ее решал здесь наверное каждый второй. :) спасибо за художественную и особенно, за техническую часть :) ок. давайте еще раз напишу задачу. может я и правда чего то не понимаю. каждые 30 секунд с 300 приборов (по каждму прибору 20 типов данных) в бд пишется значение с меткой времени. в 90% случаев эти данные никому ни нужны, но в тех самых 10% необходимо будет просмотреть каждую точку в пределах какого то минимального времени в поисках нужной информации. глубина хранения данных - 7-10 дней. больше 10 дней они никому не нужны, их не надо пересчитывать или хранить потомкам, их надо просто удалить. в связи с удалением данных, необходимо убирать мусор чтобы размер файла бд не рос совершенно дикими темпами. автоматическая сборка мусора не подходит, так как она может затормозить работу с бд совершенно непредсказуемо. остается ручная. которую мы и запускаем после того как 1. удалим данные 2. сделаем бэкап пока у нас бд только отресторенная - то по времени и скорости доступа все ок, когда проходит около недели, сборка мусора происходит какое то совершенно дикое время - что неприемлемо. Все. слушаю вопросы на уточнение и велосипед по построению систем хранения информации с датчиков ;) Заранее спасибо.
Re: ������������ ��
ïîêà ó íàñ áä òîëüêî îòðåñòîðåííàÿ - òî ïî âðåìåíè è ñêîðîñòè äîñòóïà âñå îê, êîãäà ïðîõîäèò îêîëî íåäåëè, ñáîðêà ìóñîðà ïðîèñõîäèò êàêîå òî ñîâåðøåííî äèêîå âðåìÿ - ÷òî íåïðèåìëåìî. â ïåðâûé äåíü ñáîðêà ìóñîðà - ïðîõîäèò áûñòðî, à íà âîñüìîé - äîëãî? ó òåáÿ OAT òî÷íî íå çàñòðåâàåò? è òî÷íî sweep ñðàáàòûâàåò êàæäóþ íî÷ü?
