|
|
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
Доброе время суток. Есть база Oracle 12c, в которой постепенно растёт SYSTEM tablespace. По dba_segments видно, что растёт кластер C_OBJ#. В базе ежедневно создаётся и удаляется около миллиона объектов (таблиц). Каким образом можно понять, что именно влияет на рост C_OBJ#? Индекс? И реально ли как-то остановить рост C_OBJ# при сохранении текущей логики работы БД (с созданием/удалением объектов)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 23:38 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
Kompromissпри сохранении текущей логикиследуя этой же логике, нужно ежедневно создавать и удалять бд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 08:03 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
KompromissВ базе ежедневно создаётся и удаляется около миллиона объектов (таблиц). Зачем? Кто-то перенёс "логику" 1С с динамической генерацией реестров или MS SQL с их временными таблицами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:21 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
envЗачем? Так реализована загрузка данных - создаётся External table из текстового файла, содержимое прогружается в таблицу, затем External table удаляется. Примерно 1 млн. файлов обрабатывается ежесуточно, поэтому столько же объектов создаётся/удаляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:40 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
Kompromiss, Все файлы из ежедневного 1 млн совершенно разной структуры? И совсем-совсем нельзя сделать Код: plsql 1. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:52 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:55 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
envKompromiss, Все файлы из ежедневного 1 млн совершенно разной структуры? И совсем-совсем нельзя сделать Код: plsql 1. ? Да, была такая идея - создать некоторое количество фиксированных External-таблиц, и через функцию каждый раз возвращать наименование "свободной" на данный момент. Если более подходящих вариантов не удастся найти, остановлюсь на этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 12:46 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
Kompromissнаименование "свободной"Если загрузкой занимается ограниченное число процессов, наименованием таблицы может быть номер такого процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 13:29 |
|
||
|
Увеличение размера кластера C_OBJ#
|
|||
|---|---|---|---|
|
#18+
-2-Если загрузкой занимается ограниченное число процессов, наименованием таблицы может быть номер такого процесса. Процессы запускаются по мере необходимости каждые несколько секунд. В итоге сделал фиксированное число External-таблиц, через функцию выбираю наименование свободной и использую её. Всем спасибо за советы. Но возник ещё один вопрос - можно ли как-то сжать C_OBJ# без пересоздания базы? Смущает, что запросы к некоторым системным view (user_tab_partitions, например) либо выполняются часами, либо завершаются ошибкой "snapshot too old". Объём C_OBJ# в dba_segments сейчас - около 45 Гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2017, 14:28 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39506075&tid=1885414]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
383ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
2ms |
| others: | 188ms |
| total: | 626ms |

| 0 / 0 |
