Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Оптимальное хранение данных за несколько лет  [new]
SATURN2
Member

Откуда: созвездие Проксимы
Сообщений: 74
Есть ОГРОМНАЯ таблица (допустим называется t), в которой храняться данные с 2000 года, и на которой завязано много кода. За один день может быть весено записей от 1000 и более.

Данные за 2005 г , 2004 г и т.д. никого уже не интересуют, но раз в полгода,
кого - то могут заинтересовать.

Можно ли как то рагрузить табличку ( в смысле не очень актуальные данные перееместьть в архив), но при этом не менять написанный код, где упоминается таблица t и иногда выбирать из архива данные?
28 мар 07, 22:11    [3953437]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
Вы точно прочитали про секционирование?
28 мар 07, 23:37    [3953600]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 116217
Поддерживаю alex-ls : секционирование здесь конечно напрашивается.
У Вас есть поле "год" ? Тогда можно сделать list- партиционирование
(если у Вас >= 9 иначе range- партиционирование).

Но, я бы не делал это на рабочей базе, а подгадал бы это к новому релизу
софта / миграции на новую базу.

Тогда допустима такая схема

1. В новой схеме новой базы кладется новая партиционированная таблица.
2. Старая таблица из старой базы переливается в новую схему новой базы.
3. На новую таблицу накладывается представление - срез таблицы по
нужной партиции / партициях a la

where year = fnc_get_year

Нужный год загружается с помощью глобальной функции

fnc_set_year(2006)


4. В "старой" схеме новой базы кладется синоним на представление с тем же именем,
что и таблица. Таким образом Вы достигаете прозрачности кода.

5. Конечно все это должно сопровождаться интенсивным тестированием,
чтобы планы не поплыли ...
29 мар 07, 00:32    [3953674]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
TiG
Member

Откуда:
Сообщений: 780
Если в таблице хранятся хронологические данные и запросы всегда отбирают данные за некий период - можно и существующую секционировать по дате. Вот это действительно прозрачно получится. Ну а потом - тестирование, тестирование и еще раз тестирование, прежде чем делать на боевой базе.
Но в любом случае требуется анализ кода запросов к этой таблице, без знания зачем же приложение лезет в эту таблицу выбрать наиболее оптимальный для вас вариант будет трудно -так только, указать в какую сторону смотреть ;-)
29 мар 07, 11:29    [3954796]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
SATURN2
Можно ли как то рагрузить табличку ( в смысле не очень актуальные данные перееместьть в архив), но при этом не менять написанный код, где упоминается таблица t и иногда выбирать из архива данные?

буду банален: вы хотите разгрузить (хотя термин не очень понятен). А какова конечная цель?

Поясню: ну разобъете вы на партишины, и что? у вас хранилище и вы хотите использовать partition elemination? А если у вас OLTP и 99% запросов работают в текущеем дне и по индексу? Что вам оно даст?
29 мар 07, 11:44    [3954901]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
kennethr
Member

Откуда:
Сообщений: 175
TiG
Если в таблице хранятся хронологические данные и запросы всегда отбирают данные за некий период - можно и существующую секционировать по дате. Вот это действительно прозрачно получится. Ну а потом - тестирование, тестирование и еще раз тестирование, прежде чем делать на боевой базе.
Но в любом случае требуется анализ кода запросов к этой таблице, без знания зачем же приложение лезет в эту таблицу выбрать наиболее оптимальный для вас вариант будет трудно -так только, указать в какую сторону смотреть ;-)

+1
Вариант dmidek с большой вероятностью поломает приложение. По крайней мере в такой постановке "при этом не менять написанный код". И вообще, если запрос работает неоптимально, это проблема разработчика, пусть он ее и решает. Правильно написанный запрос + индекс дадут лучший эффект.
29 мар 07, 11:46    [3954914]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Dimka9
Что вам оно даст?

Например: табличные пространства, на которых расположены "старые" разделы, переводятся в readonly, что позволяет заметно экономить на создании резервных копий и сокращает время восстановления.
29 мар 07, 11:48    [3954930]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
andrey_anonymous

я это знаю, но нужно ли оно автору?
29 мар 07, 11:50    [3954948]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
kennethr
По крайней мере в такой постановке "при этом не менять написанный код".

Согласен, в данном конкретном случае dmidek явно поторопился с выдачей рекомендаций :)
С другой стороны - обратите внимание, он больше сосредоточился на собственно технологии перевода несекционированной таблицы в секционированное состояние, что имеет самостоятельную ценность.
29 мар 07, 11:51    [3954952]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
kennethr
Member

Откуда:
Сообщений: 175
andrey_anonymous

С другой стороны - обратите внимание, он больше сосредоточился на собственно технологии перевода несекционированной таблицы в секционированное состояние, что имеет самостоятельную ценность.
Я оценил, без шуток.
29 мар 07, 11:52    [3954968]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Dimka9
andrey_anonymous

я это знаю, но нужно ли оно автору?

Почему Вы спрашиваете об этом меня?
Лично я полагаю, что для системы, в которой "очень много" данных, это нужно.
Но это далеко не единственная выгода - прежде чем задавать нигилистские вопросы, следует хотя бы спросить автора как именно он использует эти данные. Например, я практически уверен, что по таким данным гоняются отчеты. Причем в случае аналитических отчетов доступ по индексу зачастую будет не слишком эффективен - в этой ситуации partitioning нередко оказывается практически безальтернативным решением.
29 мар 07, 12:02    [3955041]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
andrey_anonymous
Почему Вы спрашиваете об этом меня?

потому что об этом сказали вы.

мне хотелось понять: нужно ускорить основные запросы или аналитику? уменьшить время бэкапа/восстановления на тестовый?

понимаете: у меня есть куча проблем и задач (перманентно). и чтобы делать то или это я хочу видеть что я получу в итоге (как можно четче, а не "разгрузить") - выгоды от того чтобы ввязнуть в работы на пару недель и затем на разгребание косяков еще на пару месяцев.
29 мар 07, 12:28    [3955260]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Dimka9
andrey_anonymous
Почему Вы спрашиваете об этом меня?

потому что об этом сказали вы.

О чем я сказал?
Потрясающая логика.
Ваши вопросы следует адресовать автору, но Вы упорно задаете их мне.
Да еще и обвиняете в попытке ввязать Вас в двухнедельный оптимизационный трип...
29 мар 07, 13:13    [3955634]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
Ваши вопросы следует адресовать автору,

они и были ему адресованы:
Поясню: ну разобъете вы на партишины, и что? у вас хранилище и вы хотите использовать partition elemination? А если у вас OLTP и 99% запросов работают в текущеем дне и по индексу? Что вам оно даст?

вы ответили в общем (и как бы за автора):
Например: табличные пространства, на которых расположены "старые" разделы,..

поэтому я и с просил вас:
но нужно ли оно автору?

согласен, вопрос был больше риторический, или лучше было сказать: "я не уверен что оно ему надо", но и вы могли ответить: "давайте дождемся его ответа"

по-моему логика обыкновенная.
29 мар 07, 13:27    [3955741]     Ответить | Цитировать Сообщить модератору
 спасибо за обсуждение мое темы  [new]
SATURN2
Member

Откуда: созвездие Проксимы
Сообщений: 74
По таблице t постоянно идет пострение отчета,
несчастніе 36тыс. строк выбираются 12 мин.

Индекс, естественно , есть, только данных многовато.

Вообще-то это не моя работа оптимизация хранения данных, а админа,
но вдруг мне прийдется такую задачу....

Мне более всего подходит вариант

автор
dmidek

Тогда допустима такая схема

1. В новой схеме новой базы кладется новая партиционированная таблица.
2. Старая таблица из старой базы переливается в новую схему новой базы.
3. На новую таблицу накладывается представление - срез таблицы по
нужной партиции / партициях a la

where year = fnc_get_year

Нужный год загружается с помощью глобальной функции

fnc_set_year(2006)
29 мар 07, 21:49    [3958384]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
SY
Member

Откуда: Middlebury, CT USA
Сообщений: 10051
SATURN2
Есть ОГРОМНАЯ таблица (допустим называется t), в которой храняться данные с 2000 года, и на которой завязано много кода. За один день может быть весено записей от 1000 и более.


Well, something is wrong with this picture:

SQL> select to_char(to_date(round(sysdate-to_date('1/1/00','mm/dd/yy'))*1000,'J'),'JSp') from dual;

TO_CHAR(TO_DATE(ROUND(SYSDATE-TO_DATE('1/1/00','MM/DD/YY'))*1000,'J'),'JSP')
------------------------------------------------------------------------------
TWO MILLION SIX HUNDRED FORTY-FIVE THOUSAND

I don't know how "более" is "и более" but 2 million rows not seem to be ОГРОМНАЯ and something tells me (based on "несчастніе 36тыс. строк выбираются 12 мин") partitioning might help, but is not the root of the issue.

SY.
29 мар 07, 22:53    [3958498]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
TiG
Member

Откуда:
Сообщений: 780
SY
SATURN2
Есть ОГРОМНАЯ таблица (допустим называется t), в которой храняться данные с 2000 года, и на которой завязано много кода. За один день может быть весено записей от 1000 и более.


Well, something is wrong with this picture:

SQL> select to_char(to_date(round(sysdate-to_date('1/1/00','mm/dd/yy'))*1000,'J'),'JSp') from dual;

TO_CHAR(TO_DATE(ROUND(SYSDATE-TO_DATE('1/1/00','MM/DD/YY'))*1000,'J'),'JSP')
------------------------------------------------------------------------------
TWO MILLION SIX HUNDRED FORTY-FIVE THOUSAND

I don't know how "более" is "и более" but 2 million rows not seem to be ОГРОМНАЯ and something tells me (based on "несчастніе 36тыс. строк выбираются 12 мин") partitioning might help, but is not the root of the issue.

SY.


Согласен, тут дело явно в самом этом отчете, а не в размере таблицы. С объемом в несколько миллионов строк вполне можно даже и без секционирования работать. Я бы предложил в первую очередь обратить внимание на сами запросы и на используемые индексы. А неправильно написанный запрос после секционирования таблицы может ведь и еще медленнее начать работать ;-)))
30 мар 07, 12:01    [3960119]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
SATURN2
Member

Откуда: созвездие Проксимы
Сообщений: 74
а МИЛИОНОВ 800 ЗАПИСЕЙ, ЄТО МНОГО?
4 апр 07, 22:56    [3981761]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальное хранение данных за несколько лет  [new]
Alex_IZA
Member

Откуда:
Сообщений: 287
По таблице t постоянно идет пострение отчета,
несчастніе 36тыс. строк выбираются 12 мин.
Индекс, естественно , есть, только данных многовато.
а МИЛИОНОВ 800 ЗАПИСЕЙ, ЄТО МНОГО?

Может быть много, а может и нет.
Смотрите в сторону секционирования ну и как писали на сам синтаксис запроса – на план запроса. Как и писали выше предварительно все хорошенько оттестировать в тестовой среде.
5 апр 07, 07:59    [3982068]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить