Добрый день!

Проблема с увеличением размера таблицы TST03
За 3 дня размер увеличился на 45Гб (1 день 6Гб, следующие по 18Гб)
Число записей 67000
rspo/store_location = db
PCTFree=10(уменьшить не даёт)

Production system
4.7x200
Kernel 6.40
Patch level 21
HP-UX 11.11
Oracle 9.2.0.8
SAP_BASIS 620 0055
SAP_ABA 620 0055
SAP_APPL 470 0025
ABA_PLUS 100 0014

Причина увеличения размера не найдена
Есть какие-нибудь мысли по решению проблемы?

Регулярно удалять старые запросы в спул.

Печатали много?

Посмотрите в sp12 какой пользователь вам такую свинью подложил и выясните что он в системе такое делает

À ïîòîì ðåîðãàíèçàöèþ òàáëè÷êè.

Максимальный размер запроса в спул - 40 Мб (единичные случаи).

В SP12 заполнение памяти 600 Мб в Базе данных. Если смотреть через Oracle - заполнение тоже 600 Мб. Фактический размер таблицы (тр.db02) = 45 Гб. Через Oracle - размер тоже 45 Гб.
Вчера проверяли на непротиворечивость (sp12) - удалили 2 тыс противоречивых записей из TST01. Также вчера добавили 12 Гб - "съел", т.е. размер растет.



Реорганизацию затеяли на вечер...

Еще из-за активного пакетного ввода может разрастись - смотри SM35

Старые (которых уже нет в системе) активные пакетники все удалены.
Активность пакетного ввода тоже не изменилась

Еще: ошибся с версией Oracle: у нас 9.2.0.6

похожие дела, TST03 сильно выросла, были большие отчеты.
Хранятся 10 дней, задание по очистке отрабатывает.
Кол-во строк меняется.

НО в sp12 заполнение памяти 6 гиг, а табличка на 26 гиг, и в db02 detailed analysis показывает что свободного места в блоках всего 11%. статистика свежая, PCTFREE стандартное 10%.

Нужно ли уменьшать PCTFREE до 1%.
чем ее реорганизовать. если
BR0280I BRSPACE time stamp: 2007-02-01 20.54.48
BR1108I Checking tables for reorganization...
BR1110W Table SAPUKP.TST03 has a LONG (RAW) column
BR1111I Reorganization of table SAPUKP.TST03 will be skipped

BR0280I BRSPACE time stamp: 2007-02-01 20.54.48
BR1113E All tables have been skipped for reorganization

ora 9.2.0.6 kernel 640

Наткнулся на ноту 934593 - может поможет?

немного. задания отрабатывают нормально, кол-во записей меняется, заполнение памяти тоже, а вот свободного места в таблице нет как нет.

Большой вопрос
Нужно ли уменьшать PCTFREE до 1%?

ЧЕМ ее реорганизовать?

brtools ругается.
а вот sapdba не ругался! но его больше нет с нами:)

У меня было тоже самое, я просто переактивировал таблицу (SE14)
Единственно, что при этом теряются на данный момент хранящиеся спулы, ну и активность системы (пользователей) желательно минимальная.

После этого запустить проверку на целостность спула, он вычистит все хвосты..

Это же ORACLE с ним иначе никак, а реорганизацией с сохранением данным здесь можно пренебречь. (Если очень хочется, то export/import утилитой ORACLE)

А у нас была проблема такая:
Решили попробовать на свежей базе таблицу реорганизовать.
Так после реорганизации она так начала рости, что съела на нашей тестовой машинке за день все свободное место.
Как с этим быть?

Вообще-то это ДАВНЫМ-ДАВНО не проблема..Мысль одна - читать одну из самых важных базисных нот 706478, а также все остальные ноты из неё вытекающие..

Вопросик - как Вы запускали проверку на целостность спула?

У меня ситуация такая: в одной системе таблица TST01 - 32070 записей. Таблица TST03 - свыше 6 миллионов записей.

Для примера в другой системе: TST01 - 869, TST03 - 373.

Нормально ли это? Может нужно запустить проверку целостности спула?