On 26.09.2008 11:35, Oleg Matveyev wrote:
Причём, это под Linux. Сдаёцца мне, что Win к памяти потребовательнее.
к тому же, если4Гб, то и лицензия на windows server намного дороже.
там ms подписка.
On 24.09.2008 8:49, Oleg Matveyev wrote:
пока у нас бд только отресторенная - то по времени и скорости доступа все
ок, когда проходит около недели, сборка мусора происходит какое то
совершенно дикое время - что неприемлемо.
в первый день сборка мусора - проходит быстро, а на восьмой - долго?
которую мы и запускаем после того как
1. удалим данные
2. сделаем бэкап
Я чуть пивом не захлебнулся.
Коваленко Дмитрий.
PS. С утра принял - ВЕСЬ день свободен!
On 24.09.2008 9:58, Oleg Matveyev wrote:
100% - все приложения с этой базой работают в стиле - открыл коннект,
записал, закрыл.
мнэ... и незакрытых коннектов / зомби не остается?
каждый час проверяю запросами к attacments и statements - там все чисто
лучше, все-таки, в статистику смотреть,
On 24.09.2008 9:43, Kovalenko Dmitry wrote:
которую мы и запускаем после того как
1. удалим данные
2. сделаем бэкап
Я чуть пивом не захлебнулся.
Коваленко Дмитрий.
PS. С утра принял - ВЕСЬ день свободен!
удалим данные которые на момент бэкапа уже не нужны. зачем они тогда в бэкапе?
On 24.09.2008 10:06, Oleg Matveyev wrote:
что делать? удалять данные, делать бэкап, удалять индексы, собирать мусор,
создавать индексы?
а) создавать только нужные,
б) непосредственно перед тем, как они понадобятся.
ты сам писал - что в 90% случаев БД непонадобится.
ну и зачем впустую байты
которую мы и запускаем после того как
1. удалим данные
2. сделаем бэкап
Я чуть пивом не захлебнулся.
удалим данные которые на момент бэкапа уже не нужны. зачем они тогда в
бэкапе?
Да я в курсе темы. Просто представленная последовательность операций
развеселила.
Кстати говоря, опять же
Alexey Voytsehovich wrote:
каждые 30 секунд с 300 приборов (по каждму прибору 20 типов данных) в бд
пишется значение с меткой времени.
Таки одной записью с 6000 полями (или одним блобом) и меткой или таки
втупую 6000 записей?
--
Regards. Ded.
On 24.09.2008 11:42, Kovalenko Dmitry wrote:
Это так, чисто _мои_ измышления на тему администрирования.
спасибо. задумаюсь.
On 24.09.2008 11:50, Ded wrote:
Alexey Voytsehovich wrote:
каждые 30 секунд с 300 приборов (по каждму прибору 20 типов данных) в
бд пишется значение с меткой времени.
Таки одной записью с 6000 полями (или одним блобом) и меткой или таки
втупую 6000 записей?
втупую 6000 записей.
в каждой
Alexey Voytsehovich wrote:
втупую 6000 записей.
в каждой записи
код прибора
код типа данных
метка времени
значение
Чтения с Where Код_Прибора= и Код_Типа_Данных= в приложении нужны?
Если отбирается всё всегда по метке, то это просто оверкилл для сервака.
--
Regards. Ded.
On 24.09.2008 12:57, Ded wrote:
Alexey Voytsehovich wrote:
втупую 6000 записей.
в каждой записи
код прибора
код типа данных
метка времени
значение
Чтения с Where Код_Прибора= и Код_Типа_Данных= в приложении нужны? Если
отбирается всё всегда по метке, то это просто оверкилл для сервака.
Alexey Voytsehovich wrote:
втупую 6000 записей.
в каждой записи
код прибора
код типа данных
метка времени
значение
Чтения с Where Код_Прибора= и Код_Типа_Данных= в приложении нужны? Если
отбирается всё всегда по метке, то это просто оверкилл для сервака.
конечно. рисуются тренды
On 24.09.2008 13:15, Ded wrote:
Alexey Voytsehovich wrote:
втупую 6000 записей.
в каждой записи
код прибора
код типа данных
метка времени
значение
Чтения с Where Код_Прибора= и Код_Типа_Данных= в приложении нужны? Если
отбирается всё всегда по метке, то это просто оверкилл для сервака.
Тогда блоб не годится.
Шепотом: может массивы?.
И бегом в укрытие. :-)
Коваленко Дмитрий.
Kovalenko Dmitry wrote:
Тогда блоб не годится.
Шепотом: может массивы?.
И бегом в укрытие. :-)
А що массивы. Слово-то красивое, а на практике тот же блоб. Искать по
элементу невозможно.
--
Regards. Ded.
А що массивы. Слово-то красивое, а на практике тот же блоб. Искать по
элементу невозможно.
Ну, мона рекуест в трекер написать (наверняка там такое есть). А потом
позырить на реакцию ООН. Наверняка санкцию нало... не какое то странное
предложение получается. Лучше так - вынесут
упираемся в необходимость периодической рестуктуризации по ходу
разматывания диалектической спирали жызни.
Ну вот, опять интеллектом задавили, я бы даже сказал придушили, робкую
надежду найти массивам хоть какое то полезное применение. Не считая моего
садомазохического увлечения ими :-)
On Sep 24, 1:32 pm, Ded [EMAIL PROTECTED] wrote:
Alexey Voytsehovich wrote:
CREATE INDEX IDX_MOMDATA1_NEW1 ON MOMDATA(ARDTIMESTAMP);
CREATE DESC INDEX IDX_MOMDATA2_NEW1 ON MOMDATA(ARDTIMESTAMP);
CREATE INDEX IDX_MOMDATA4_NEW1 ON
MOMDATA(DEVID,TYPEDEVICE,CHANNELID,ARDTIMESTAMP);
при
Kovalenko Dmitry wrote:
упираемся в необходимость периодической рестуктуризации по ходу
разматывания диалектической спирали жызни.
Ну вот, опять интеллектом задавили, я бы даже сказал придушили, робкую
надежду найти массивам хоть какое то полезное применение. Не считая
моего
Ded wrote:
Эт точно. В смысле насчёт угы-гы. Фичка-то бесполезная практицки. Сам
видишь - даже там, где, на первый взгляд вроде и могло бы пригодится, в
смысле типа приборных данных, упираемся в необходимость периодической
рестуктуризации по ходу разматывания диалектической спирали жызни.
On 23.09.2008 14:37, Oleg Matveyev wrote:
Если 7 дней зашито в ТЗ,
то зашить в БД 7 таблиц - по одной на день :-)
имена таблицам дать фиксированные, накрутить на них вьюх...
раз в день одну таблицу пересоздавать.
то есть алгоритм таков
создали 7 внешних таблиц
создали view имитирующий
On 23.09.2008 14:59, Oleg Matveyev wrote:
то есть алгоритм таков
да, как-то сложно получается :-)
а шо делать
создали 7 внешних таблиц
хмм... я вообще-то не имел ввиду внешние таблицы.
а другие ведь все равно будут делать фрагментацию?
хотя со внешними таблицами вариант интересный. уже
On 23.09.2008 15:20, Alexey Voytsehovich wrote:
хотя со внешними таблицами вариант интересный. уже упоминалось.
Остановить FB, и файл удалить, и создать новый, пустой.
можно и без остановки ФБ. удаляется таблица на лету.
поторопился. удалятся то удаляется. логически. но данные все равно
On 23.09.2008 15:28, Oleg Matveyev wrote:
поторопился. удалятся то удаляется. логически. но данные все равно
остаются. точно придется еще и физический файл грохать. в общем буду
читать и искать.
как раз в данном случаее тебе проще только файл удалить.
а таблицу в бд не трогать.
только процесс
Oleg Matveyev ...
поторопился. удалятся то удаляется. логически. но данные все равно остаются. точно придется еще и физический файл грохать. в
общем буду читать и искать.
как раз в данном случаее тебе проще только файл удалить.
а таблицу в бд не трогать.
только процесс FB будет файл
On 23.09.2008 15:50, Vlad Khorsun wrote:
2.1 отпускает файл как только все запросы к нему освобождены.
у меня даже 2.5 :)
Т.е. если нет процедур\триггеров, обращающихся ко внешним таблицам,
то останавливать FB не нужно.
может посоветуешь как мне тогда решить проблему с view (в которой
Alexey Voytsehovich ...
может посоветуешь как мне тогда решить проблему
Пока PS (из первого поста) не опишешь - никаких вразумительных советов
быть просто не может.
--
Хорсун Влад
у меня даже 2.5 :)
Запомним это.
может посоветуешь как мне тогда решить проблему с view (в которой будут
объединены данные из 7 внешних таблиц, по таблице на день)?
то есть я буду создавать к примеру 7 внешних таблиц, в них будут данные. когда
наступает 8-й день мне необходимо таблицу в
Доброго времени суток!
PEAKTOP пишет:
Идея в общем такая: семь баз по дням недели. Демон (LINUX) или сервайс
(Windows), который эти самые базы создает и, соответственно, убивает
уже ненужные. В базах - одна и та же таблица, а выборка - через CROSS-
DATABASE запросы оператора EXECUTE STATEMENT.
Кузнецов Евгений пишет:
Действительно, 7 БД по дням недели + 1 управляющая БД, хранящая всю
логику и сведения об остальных. А проблему блокировки старых данных
можно решить через shutdown.
Тут, правда, некоторая проблема с алиасами возникает - либо их нужно
динамически перезначать, либо от
Кузнецов Евгений ...
Доброго времени суток!
PEAKTOP пишет:
Идея в общем такая: семь баз по дням недели. Демон (LINUX) или сервайс
(Windows), который эти самые базы создает и, соответственно, убивает
уже ненужные. В базах - одна и та же таблица, а выборка - через CROSS-
DATABASE запросы
Доброго времени суток!
Vlad Khorsun пишет:
Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки
данных.
Согласен.
По идее старые БД не должны быть никогда и никем использованы.
В принципе, да. Но когда я предлагал хранить ежедневные данные в
отдельных таблицах, и
On 23.09.2008 20:20, Vlad Khorsun wrote:
Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки
данных.
так и думал. а еще думал данные отдавать с хранимки по одной, константной бд,
которая будет динамически строить и выполнять запросы к другим бд.
По идее старые БД не должны
Кузнецов Евгений ...
Доброго времени суток!
Vlad Khorsun пишет:
Зачем ? Положить имена известных БД в таблицу. Туда же - дата заливки данных.
Согласен.
По идее старые БД не должны быть никогда и никем использованы.
В принципе, да. Но когда я предлагал хранить ежедневные данные в
Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут
выполняться в другом процессе?
На тот же хост с тем же портом - не будут. Если же использовать
локальный
коннект, то это будет embedded соединение.
А это embedded будет фактически подключением а-ля классик ?
Ну в смысле,
Kovalenko Dmitry ...
Интересно, кстати, CROSS-DATABASE запросы в SuperClassic будут выполняться в
другом процессе?
На тот же хост с тем же портом - не будут. Если же использовать локальный
коннект, то это будет embedded соединение.
А это embedded будет фактически подключением а-ля
On 24.09.2008 2:33, Alexey Abramov wrote:
может посоветуешь как мне тогда решить проблему
Пока PS (из первого поста) не опишешь - никаких вразумительных советов
быть просто не может.
Задача ассинхронного снятия данных с датчиков, и хранения этих данных
воообщем примитивна, сто раз
38 matches
Mail list logo
