powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Архивирование данных
39 сообщений из 39, показаны все 2 страниц
Архивирование данных
    #39411846
wolfio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте.

Пожалуйста, подскажите, названия каких-нибудь технологий архивации данных БД Oracle (12c), которые просто внедрить, и не трудно сопровождать? Которые можно использовать для архивации данных, при переполнении табличных пространств.

Мне для гуглинга. Не откажусь от дельных и внятных рекомендаций.

Просьба без хейтинга, я прикладник. Придумываю работу для страдальцев-ДБА
...
Рейтинг: 0 / 0
Архивирование данных
    #39411852
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня вот сейчас аналогичная задача, начал с компрессирования, там, где это осмыслено. Table compress, key compress.
...
Рейтинг: 0 / 0
Архивирование данных
    #39411853
wolfio,

Compress для начала
...
Рейтинг: 0 / 0
Архивирование данных
    #39411871
wolfio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
как я понял из описания compression, нужно перезаливать данные из несжатой таблицы/пространства в сжатую? если так, то это довольно дорогой вариант. Вариант с alter compression ..move кажется еще дороже..
какие еще бывают технологии?

Подскажите, пожалуйста, сворачивание на ленту части таблицы возможно? если да, то как? (имею ввиду не перенос из большой в пустую лишних данных, а именно ее отрезание какой-нибудь архивирующей технологией)
...
Рейтинг: 0 / 0
Архивирование данных
    #39411872
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Архивирование данных
    #39411878
wolfio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
к тому же интернет говорит, что загрузка данных в сжатую таблицу замедляется почти в 2 раза. Этот вариант не подходит.

Есть еще?
...
Рейтинг: 0 / 0
Архивирование данных
    #39411890
Jafa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfio,
процесс скользящего окна
...
Рейтинг: 0 / 0
Архивирование данных
    #39411891
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfio,
вы б для начала своих страдальцев-ДБА спросили, что ли
а то пойдете потом лесом со своими нагугленными нововведениями
...
Рейтинг: 0 / 0
Архивирование данных
    #39411893
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВА,

Я вот своего не спросил. Ворчит.
...
Рейтинг: 0 / 0
Архивирование данных
    #39411895
AmKad, секционирование с удалением/переносом в другую базу на говнодисках через exchange partition и transportable tablespace
...
Рейтинг: 0 / 0
Архивирование данных
    #39411922
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Партиционирование - это да, а вот к переносу данных во вновь созданную говнобазу, в которой будут продублированы сущности с точно такой же структурой, к решению проблем с доступа к этим же говноданным при необходимости, я пока не готов.
...
Рейтинг: 0 / 0
Архивирование данных
    #39411938
AmKad, но это проще, чем из бэкапа их тащить :)
...
Рейтинг: 0 / 0
Архивирование данных
    #39411986
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нарезатель,

И? Ты предлагаешь перепартиционирование. Считаешь, что перекомпрессия принципиально сложнее?
...
Рейтинг: 0 / 0
Архивирование данных
    #39411992
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfioкак я понял из описания compression, нужно перезаливать данные из несжатой таблицы/пространства в сжатую? если так, то это довольно дорогой вариант. Вариант с alter compression ..move кажется еще дороже..А тебе самому не кажется абсурдной твоя хотелка, если ты хочешь сжать при этом, чтоб данные остались как есть?
wolfioк тому же интернет говорит, что загрузка данных в сжатую таблицу замедляется почти в 2 разаПеречитай интернет еще разок.
Вкратце, если таблица сжата, то вновь вставленные данные в conventional insert будут несжатыми, а в direct path insert сжатыми.
Скорость может проседать в очень специфических случаях для conventional insert и не в два раза.
Иными словами, может получится так что данные в некоторых блоках сегмента сжаты, а в некоторых нет.

Крайне прискорбно когда такие "специалисты" еще имеют наглость для кого-то придумывать работу.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412070
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbms_photoshopВкратце, если таблица сжата, то вновь вставленные данные в conventional insert будут несжатыми, а в direct path insert сжатыми.
В доке заявлено, что compress for oltp (он же for all operations) в отличие, например, от basic, работает для всех DML операций. В частности, для conventional insert он работает.
Тест
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
column segment_name format a30
set timing off

select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production


select t2.block_size, t2.logging, t2.extent_management, t2.segment_space_management, t2.def_tab_compression
from       dba_users       t1
inner join dba_tablespaces t2 on t1.default_tablespace = t2.tablespace_name
where t1.username = user;

BLOCK_SIZE LOGGING   EXTENT_MAN SEGMEN DEF_TAB_
---------- --------- ---------- ------ --------
     16384 LOGGING   LOCAL      AUTO   DISABLED


create table test_without_compression(f varchar2(100 char));

Таблица создана.


create table test_with_compression   (f varchar2(100 char)) compress for oltp;

Таблица создана.


set timing on

insert into test_without_compression(f)
select decode(mod(rownum, 5)
                    ,0, rpad('a', 100, 'a')
                    ,1, rpad('b', 100, 'b')
                    ,2, rpad('c', 100, 'c')
                    ,3, rpad('d', 100, 'd')
                    ,4, rpad('e', 100, 'e')
             ) f
from dual
connect by level <= 1e5;

100000 строк создано.

Затрач.время: 00:00:00.38

set autotrace on explain

insert into test_with_compression(f)
select decode(mod(rownum, 5)
                    ,0, rpad('a', 100, 'a')
                    ,1, rpad('b', 100, 'b')
                    ,2, rpad('c', 100, 'c')
                    ,3, rpad('d', 100, 'd')
                    ,4, rpad('e', 100, 'e')
             ) f
from dual
connect by level <= 1e5;

100000 строк создано.

Затрач.время: 00:00:01.31

План выполнения
----------------------------------------------------------
Plan hash value: 1731520519

------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                  | Rows  | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT               |                       |     1 |     2   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL       | TEST_WITH_COMPRESSION |       |            |          |
|   2 |   COUNT                        |                       |       |            |          |
|*  3 |    CONNECT BY WITHOUT FILTERING|                       |       |            |          |
|   4 |     FAST DUAL                  |                       |     1 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter(LEVEL<=1e5)

Note
-----
   - automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold


set autotrace off
set timing off

select segment_name, segment_type, bytes, bytes / power(1024, 2) mb
from user_segments
where segment_name like 'TEST_WITH%COMPRESSION';

SEGMENT_NAME                   SEGMENT_TYPE            BYTES         MB
------------------------------ ------------------ ---------- ----------
TEST_WITHOUT_COMPRESSION       TABLE                12582912         12
TEST_WITH_COMPRESSION          TABLE                 2097152          2


drop table test_without_compression purge;

Таблица удалена.

drop table test_with_compression purge;

Таблица удалена.

Исходный код для желающих поиграться
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
column segment_name format a30
set timing off

select * from v$version;

select t2.block_size, t2.logging, t2.extent_management, t2.segment_space_management, t2.def_tab_compression
from       dba_users       t1
inner join dba_tablespaces t2 on t1.default_tablespace = t2.tablespace_name
where t1.username = user;

create table test_without_compression(f varchar2(100 char));

create table test_with_compression   (f varchar2(100 char)) compress for oltp;

set timing on

insert into test_without_compression(f)
select decode(mod(rownum, 5) 
                    ,0, rpad('a', 100, 'a')
                    ,1, rpad('b', 100, 'b')
                    ,2, rpad('c', 100, 'c')
                    ,3, rpad('d', 100, 'd')
                    ,4, rpad('e', 100, 'e') 
             ) f       
from dual
connect by level <= 1e5;

set autotrace on explain

insert into test_with_compression(f)
select decode(mod(rownum, 5) 
                    ,0, rpad('a', 100, 'a')
                    ,1, rpad('b', 100, 'b')
                    ,2, rpad('c', 100, 'c')
                    ,3, rpad('d', 100, 'd')
                    ,4, rpad('e', 100, 'e') 
             ) f       
from dual
connect by level <= 1e5;

set autotrace off
set timing off

select segment_name, segment_type, bytes, bytes / power(1024, 2) mb
from user_segments
where segment_name like 'TEST_WITH%COMPRESSION';

drop table test_without_compression purge;
drop table test_with_compression purge;

...
Рейтинг: 0 / 0
Архивирование данных
    #39412078
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfioкак я понял из описания compression, нужно перезаливать данные из несжатой таблицы/пространства в сжатую? если так, то это довольно дорогой вариант. Вариант с alter compression ..move кажется еще дороже..Move избавляет тебя от необходимости делать drop/create/rename (со всеми вытекающими проблемами доступа к данным) + grant + disable/enable fk + comment. У move конечно тоже есть побочный эффект - инвалидация индексов (для приложения это тоже может пройти с определенными проблемами), а значит появляется необходимость их перестроения. Но раз ты встал на православный путь компрессии, то весомую часть из-них так или иначе имеет смысл rebuild-ить c кляузой compress.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412100
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
AmKadтак или иначе имеет смысл rebuild-ить c кляузой compressпо моему скромному опыту для oltp-систем чаще выгоднее включать компрессию только для архивных секций (или делать сплит периодически с компрессией), но индексы не сжимать
...
Рейтинг: 0 / 0
Архивирование данных
    #39412101
AmKadимеет смысл rebuild-ить c кляузой compress.я б для начала прошелся по индексам analyze-м (Analyze Index Validate Structure), посмотрел чего оно покажет (select * from index_stats, только нужно помнить, что там храниться всегда одна строка для последнего проанализированного индекса), а уж после бы принимал решение о включении компрессии по тому или иному индексу....
А то может оказаться, что овчинка и выделки-то не стоит...
...
Рейтинг: 0 / 0
Архивирование данных
    #39412142
wolfio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbms_photoshop,

простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа.


компрессия не подходит потому, скорость записи и чтения данных не должна измениться.
Задача вообще стоит так - минимизировать рост табличных пространств с индексами, соответственно. При этом хотелось бы просто выдергивать архивные данные, и убирать куданибудь в бэкап, очищая забитую в экстентах память.

Кстати, если, допустим, таблица весит 1тб, индекс ну скажем 200гб, то удалив 500гб из таблицы индекс уменьшится сам? или его нужно пересоздавать?
...
Рейтинг: 0 / 0
Архивирование данных
    #39412154
fortnet
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfio,

Партицировать и перемещать старые партиции. Глобальные индексы перестраивать (rebuild).
...
Рейтинг: 0 / 0
Архивирование данных
    #39412161
wolfio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fortnet,
мне сказали, что партицирование не подходит как технология, потому что занимает слишком много времени создание партиций с переносом данных.
хотя хз конечно, 1 раз перетерпеть можно было бы, но это я так думаю.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412165
wolfio,

любая "технология архивирования" для своей первоначальной "инициализации" потребует слишком много времени и ресурсов. потому как данные всё равно придется перемещать, иначе, как уже было замечено, как ты без ворошения данных сделаешь так, чтобы они стали занимать меньше места?

ну и поверь уже, компрессия не так уж и сильно скажется на производительности. Скорее всего, её влияния в этом аспекте ты даже и не заметишь...
...
Рейтинг: 0 / 0
Архивирование данных
    #39412198
fortnet
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfiofortnet,
мне сказали, что партицирование не подходит как технология, потому что занимает слишком много времени создание партиций с переносом данных.
хотя хз конечно, 1 раз перетерпеть можно было бы, но это я так думаю.

Нет сомнений в том, что они уже имеют большой опыт в этом. :)
...
Рейтинг: 0 / 0
Архивирование данных
    #39412326
Фотография Vivat!San
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - Эх
ну и поверь уже, компрессия не так уж и сильно скажется на производительности. Скорее всего, её влияния в этом аспекте ты даже и не заметишь...


enq: TX - allocate ITL entry легко могут приехать, если не позаботиться об этом заранее.
К тому же багов полно ещё на компрессии.
Например,
ALERT Bug 21923026 Corruption during Recovery after upgrading to 12c for Compressed Tables (Doc ID 2058461.1)
...
Рейтинг: 0 / 0
Архивирование данных
    #39412503
Kumotori
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
wolfio... сворачивание на ленту части таблицы возможно?

А вы забумывались про:
Какова процедура доступа к данным, которые вы сбрасываете на ленту?
Сможете восстановить хотя бы 5-ти летние данные? (старые ленты не всегда читаются)
А если у вас не будет совместимого устройства для чтения старых лент? (личный опыт)
А если у вас не будет БД Oracle? (например оптимизация и переход на P...sql и т.п.)
А если у вас не будет своих спецов, а только аутсорс и на удаленке без физического доступа?
и так далее.

Если для вас затраты на хранилище в бОльшем приоритете, чем данные, тогда такие "данные" можно удалять.
А если данные важнее, тогда и компрессия не страшна.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412509
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfiodbms_photoshop,

простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа.


Совершенно верно. Это не их работа, а архитектора системы
...
Рейтинг: 0 / 0
Архивирование данных
    #39412511
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AmKadDВА,

Я вот своего не спросил. Ворчит.

то что он ворчит, вобщем-то наплевать и забыть, а вот то, что нагугленное решение может в принципе не подходить для данной системы - это уже другой вопрос
...
Рейтинг: 0 / 0
Архивирование данных
    #39412533
Jafa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfiofortnet,
мне сказали, что партицирование не подходит как технология, потому что занимает слишком много времени создание партиций с переносом данных.
хотя хз конечно, 1 раз перетерпеть можно было бы, но это я так думаю.
складывается впечатление, что вы уже и сами не знаете чего хотите. Если у вас непродуманная архитектура бд, то практически любое ее изминение будет болезненым. Если вы больше не хочете раздувать свой hard-массив, то выбирайте партиционирование с замещением старых партиций новыми, темболее что от версии к версии этот механизм совершенствуется, например в версии 12c глобальные индексы уже можно обслуживать аснхронно, а партиции каскадно. Также незабывайте контролировать размеры: temporary space, логов, бэкапов и т.д.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412610
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AmKadВ доке заявлено, что compress for oltp (он же for all operations) в отличие, например, от basic, работает для всех DML операций. В частности, для conventional insert он работает.
Всё верно. Я подразумевал basic.
Если в твоем тесте
1) поменять тип на basic
2) увеличить число строк до 1e6
3) добавить --+ append
то результаты будут такими

Код: plaintext
1.
2.
3.
1000000 rows created.
Elapsed: 00:00:02.51
1000000 rows created.
Elapsed: 00:00:03.23

Код: plaintext
1.
2.
3.
SEGMENT_NAME                   SEGMENT_TYPE            BYTES         MB
------------------------------ ------------------ ---------- ----------
TEST_WITHOUT_COMPRESSION       TABLE               125829120        120
TEST_WITH_COMPRESSION          TABLE                12582912         12

Время примерно одинаковое. Сжатие для этих специфических данных в 10 раз.
При conventional никакого эффекта не будет ни по времени ни по сжатию.

Если вернуться к compress for oltp, то целесообразность подобного компромисса весьма сомнительна
1. Компрессия как правило применяется к архивным данным, а не активным
2. Прирост нагрузки на CPU таким может быть ощутимым
3. При удалениях и последующих вставках ожидаемого сжатия может не быть.
Имеет множество случаев когда работает "весьма странно". В свое время была у меня подборочка, когда анализировали разные типы.
Можно нагуглить много интересного начиная от блога Льюиса и заканчивая этим форумом move compress for oltp .
...
Рейтинг: 0 / 0
Архивирование данных
    #39412615
Q.Tarantino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfioк тому же интернет говорит, что загрузка данных в сжатую таблицу замедляется почти в 2 раза. Этот вариант не подходит.

Есть еще?
так сперва обычно партицируют исторические данные и потом старые партиции сжимают. на вставку в текущую партицию никак это не влияет.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412633
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfiodbms_photoshop,

простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа.


компрессия не подходит потому, скорость записи и чтения данных не должна измениться.
Задача вообще стоит так - минимизировать рост табличных пространств с индексами, соответственно. При этом хотелось бы просто выдергивать архивные данные, и убирать куданибудь в бэкап, очищая забитую в экстентах память.

Кстати, если, допустим, таблица весит 1тб, индекс ну скажем 200гб, то удалив 500гб из таблицы индекс уменьшится сам? или его нужно пересоздавать?Я эникейщик, а не админ, не стоит извинений.
Стоит только больше думать и читать перед тем как писать.

Все твои суждения про целесообразность (или ее отсутствие) выглядят весьма нелепо из-за крайне низкого уровня знаний и соотвественно бестолковых выводов.
Для того, чтоб минимизировать время простоя ты можешь рассмотреть dbms_redefinition, edition based redefinition или просто грамотное планирование действий в окне простоя системы.
Касаемо скорости записи, как уже было сказано, при испольвании basic и секционирования ты добьешься и сжатия архивных данных (не это ли заголовок твоей темы) и неизменную скорость работы с активными данными.
И самое главное, чтоб подумать и предложить что-то дельное не надо быть специалистом с 25 лет опыта Оракла, достаточно почитать доку, блоги, презентации + много экспериментов.
Ты же просто предлагаешь какие-то инициативы имея крайне поверхностное понимание. И одно дело, если б ты просто определил цель, но ты же строишь нелепые концепции и пытаешься указывать другим.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412638
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kumotoriwolfio... сворачивание на ленту части таблицы возможно?

А вы забумывались про:
Какова процедура доступа к данным, которые вы сбрасываете на ленту?
Сможете восстановить хотя бы 5-ти летние данные? (старые ленты не всегда читаются)
А если у вас не будет совместимого устройства для чтения старых лент? (личный опыт)
А если у вас не будет БД Oracle? (например оптимизация и переход на P...sql и т.п.)
А если у вас не будет своих спецов, а только аутсорс и на удаленке без физического доступа?
и так далее.

Если для вас затраты на хранилище в бОльшем приоритете, чем данные, тогда такие "данные" можно удалять.
А если данные важнее, тогда и компрессия не страшна.Хорошая попытка блеснуть умом, только
Код: plaintext
1.
2.
Retention policy
Compression strategy
Backup schedule
Это три разные вещи.

Часто ты при разработке политики архивирования думаешь, что будет если в будущем не будет Оракл и своих спецов?
Я надеюсь возможный ядерный взрыв тоже учитываешь?
...
Рейтинг: 0 / 0
Архивирование данных
    #39412653
Vint
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbms_photoshop, немного offtop
вчера вот только в райфе слушал недо_scna, он рассказывал про hadoop и сопутствующие технологии типа oracle big data lite, external tables над hdfs. вот думаю после переезда на 12 попробовать как раз вариант поиграться с вариантами, пока придумал такие:
партицирование и compress данных старше 1 года на некоторых фактических таблицах.
view+ insted of trigger над таблицей с данными за последний год+таблица с историческими данными без индексов
ну и на крайний случай
view+ insted of trigger над таблицей с данными за последний год+external tables над hdfs
скорее всего конечно будет партицирование со сжатием. все таки намного проще реализуемо, но и другие варианты тоже продумываю, еще можешь подкинуть что-то на подумать? данные важны только за текущий год. скорость предыдуших годов не важна. горячие данные только текущий и предыдущий месяц.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412660
fortnet
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfiodbms_photoshop,

простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа.


А вы на общественных началах, так сказать, пытаетесь решить задачу.
Не стоит делать чужую работу. А вашим специалистам где бы не работать, лишь бы не работать.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412719
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vintdbms_photoshop, немного offtop
вчера вот только в райфе слушал недо_scna, он рассказывал про hadoop и сопутствующие технологии типа oracle big data lite, external tables над hdfs. вот думаю после переезда на 12 попробовать как раз вариант поиграться с вариантами, пока придумал такие:
партицирование и compress данных старше 1 года на некоторых фактических таблицах.
view+ insted of trigger над таблицей с данными за последний год+таблица с историческими данными без индексов
ну и на крайний случай
view+ insted of trigger над таблицей с данными за последний год+external tables над hdfs
скорее всего конечно будет партицирование со сжатием. все таки намного проще реализуемо, но и другие варианты тоже продумываю, еще можешь подкинуть что-то на подумать? данные важны только за текущий год. скорость предыдуших годов не важна. горячие данные только текущий и предыдущий месяц.
Не очень понял зачем insted of trigger. Для хранилищ должны быть очень серьезные аргументы в пользу такого решения.

Data Offload счас предлагают все кто не лень от Oracle и MSSQL и заканчивая специфическими приблудами типа Gluent Smart Connector от Подера.

Я вижу смысл оффлоадить данные только если можно также оффлоадить не только примитивные фильтры и projection, но и такие операции как групировка и при этом данные нужны в более агрегированном виде чем они хранятся (ну или фильтры хорошо фильтруют данные).
Иначе, по факту, only scanning + selection + projection will be offloaded, после чего здоровенная порция данных будет перекачана из hadoop кластера в Oracle для последующих соединений и прочего.

Ясное дело, о выполнении оракловой специфики типа connect by на стороне hadoop и речи быть не может.
По крайней мере на данном этапе развития технологий.
Хотя работу аналитических функций в ближайшие годы, вероятно, может будет вынести.
Они уже реализованы и в Oracle и в той же Impala, но проблема распределить работу.

Для старта - я рекомендовал бы ознакомиться с презентацией Подера Connecting Hadoop and Oracle , потом углябляться в интересующие моменты.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412770
wolfio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbms_photoshop,

ты бы не воспринимал все так в штыки..
форум вроде как для того и нужен, чтобы по теме общаться, разве нет? мне показалось, что лучше спросить опытных людей, чем читать доку. тем более, что я ограничен временем, а от меня, как от прикладника, не требуется реализация. Требовалась просто идея для обсуждения.

изначально я и спросил ключи для гуглинга.

в любом случае, сейчас вопрос уже не актуален.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412780
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wolfioмне показалось, что лучше спросить опытных людей, чем читать докуДа, тебе показалось.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412872
drema201
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbms_photoshop,

По поводу Gluent
можно еще здесь посмотреть:
https://vimeo.com/196497024
на мой вкус чуть больше деталей.
...
Рейтинг: 0 / 0
Архивирование данных
    #39412968
Vint
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbms_photoshop,
насчет ограничений sql это то понятно, как и насчет большого объема перекачки в некоторых случаях. просто обдумываю пока направления в которых копать. и смотрю документацию и презенташки. Про подера как раз позавчера слышал, скоро доберусь посмотреть) спасибо.

drema201,
Ну вот, а говорил, что на форуме бывает редко))
...
Рейтинг: 0 / 0
39 сообщений из 39, показаны все 2 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Архивирование данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]