Привет всем,
мы делаем апгрэйд по схеме 4.6C -> ERP2005 продуктивной системы, среду разработки и тестовую систему( которая кстати является полной копией продуктивной системы) отапгрэйдили месяца 4 назад, потом полностью все протестировали и восстановили функциональность и все начали радоваться и смеяться, а зря - рано радовались... В прошлый вторник я начал делать апгрэйд продуктива, так сказать по накатанным рельсам, и тут начались странности с Oracle-ом внезапно начало стремительно разрастаться в размерах табличное пространство PSAPSR3 - я в течении четырех часов НЕПРЕРЫВНО, пачками по 5 файлов каждый из которых = 5 Gb расширял PSAPSR3, но база росла гораздо быстрее чем я вставлял файлы, поэтому начался рост уже созданных файлов до 10 Gb. В итоге база в конце апгрэйда составила 1.2Tb, хотя расчетный объем должен быть не более 150Gb. Я был удивлен этим фактом, однако впереди была конвертация в Unicode и я сильно не расстраивался. Действительно после конвертации в Unicode база уменьшилась в размерах, но только в 2 раза и составляет сейчас примерно 600 Gb. Я сравнил размеры показательно больших таблиц, например BKPF, COEP, VBAK и т.п. в продуктивной и тестовой системе - они расходятся на единицы процентов(так и должно быть), а количество записей в закрытых периодах ИДЕАЛЬНО совпадает!

Возникает вопрос кто сожрал базу? и что делать для уменьшения размера? понятно, надо сделать экпорт-импорт, но это не приводит к положительному результату!!! в чем то здесь есть засада... Кстати, функционал ERP2005 поднялся идеально, на конечных пользователях эта проблема никак не отражается.

проанализируйте таблицы, которые внезапно выросли. И дальше видно будет что делать. Скорее всего конвертация шла. (предположение такое). Нужен анализ.

вот только как их найти? таблиц-то много и это продуктивная система, как мне определить "что такое хорошо, а что плохо"?

dbacockpit->space->Segments->Overview
Top growth

(если статистика собирается и все настроено)

детальный анализ показал, что таблицы занимают в базе 62Gb, а вот индексы аж 530Gb
откуда такие страшные размеры индексов??? Самое интересное через DBACOCKPIT я не могу
найти НИЧЕГО необычного, например топы по размерам индексов и таблиц в тестовой и продуктивной системе примерно одинаковые,
а вот в целом разница гигантская...

в базе таблицы 62Gb, а вот индексы аж 530Gb - ну вот ваши 600 Гиг. Да кстати я советовала анализировать не топы - а наиболее быстро растущие таблицы - это несколько разные вещи. Если мне не изменяет память там и индексы есть... в dbacockpit.
По крайней мере можно сбросить размер всех сегментов в ёксель и там уже играть с данными как хочется.

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

совершенно точно есть нота, описывающая процедуру апгрэйда с 46 47 на ЕРП, там описана процедура, которая отключает автоматическое удаление кластерных таблиц после преобразования оных. Это сделано для того, что после включения в таблицы новых полей есть вероятность того, что данные не будут перенесы корректно и проверять перенос предлагается вручную и только после этого таблицы удаляются вручную системным администратором. Поройтесь на САПнотах, возможно это ваш случай... Быстро проверить это скорее всего можно прямым запросом к базе выбрать все таблицы, где владелец SAPSHD+(не помню точно владельца) в крайнем случае указать где владелец не SAPR3 и SAPSR3

у меня нет проблем с таблицами(про кластерные таблицы я разумеется читал еще 4 месяца назад, когда делал первый апгрэйд), проблемы только с индексами. Я активировал Oracle EMC-консоль для целей мониторинга и в первую очередь проверил наличие схемы "SAPSHD+(не помню точно владельца)", которая используется для конвертации данных во время апгрэйда - ее в базе нету!

я не против реорганизации, но я же ее УЖЕ по сути сделал, когда выполнял конвертацию в Unicode, однако индексы опять создались огромных размеров... Кстати, когда делаешь реорганизацию через brtools можно ли:
1. выполнять реорганизацию табличного пространства в несколько потоков?
2. разделять реорганизацию больших таблиц на части, например разбить таблицу BKPF на 10 равных частей и запустить параллельно 10 потоков реорганизации?
3. я не понял фразу "и освобождении свободного места", как именно освобождается место? удаляются файлы данных? или появляются "дырки" в табличном пространстве?

на первые два вопроса у меня нет ответа - давно не смотрела возможности новых brtools - но Oracle умеет параллелить процессы - в том числе и создания индексов.
3. есть несколько вариантов освобождения свободного места - выбирается как опции при реорганизации - в том числе и полностью пересоздание файлов базы данных. По умолчанию реорганизация не ведет ни к освобождению занятого места в таблицах - ни тем более удалению файлов.

ЗЫ не могут просто так индексы создаваться огромными....
Можно попытать удалить самые большие индексы и пересоздать - посмотреть что из этого получится. Можно все индексы удалить и пересоздать - как шаг процедуры полной реорганизации. Большие индексы получаются если в таблице были проведены очень большие изменения. rebuild помогает.

ну нету у меня экстремально больших индексов!!! чего мне удалять и пересоздавать? во всяком случае DBACOCKPIT ничего найти не может, такое ощущение, что несмотря на разумные размеры индексов, которые хорошо видно в DBACOCKPIT, физически они занимают гигантское место на дисковом массиве. Единственно на что я грешу, т.к. это то, что версия Oracle при апгрэйде тестовой системы была 10.2.0.2, а на продуктиве я сначала поставил патч-сет 10.2.0.4, а только потом начал апгрэйд...

600Гиг занято индексами. И отсутствуют индексы больших размеров.
Осталось только их всех выбрать - и выгрузить в ёксель и сравнить с тестовой системой - откуда 600 гиг.
А мне осталось только как САП:) - дайте доступ к системе:) больше виртуальных идей нет - надо смотреть

а что такое за параметр UNIFORM при создании табличного пространства? дело в том, что он с определенной версии brspace стал обязательным параметром при создании табличного пространства и похоже я задал его значение 20Mb(и как это проверить?) во время апгрэйда. я щас нашел ноту "Note 1109743 - Use of Index Key Compression for Oracle Databases" по которой можно автоматизировать перестроение индексов, на тестовой системе уже опробовал - освободились сущие копейки, однако в самом конце ноты есть фраза, типа если вы задали большое значение UNIFORM , то пересоздание индексов может и не дать экономии пространства. Светлана, что Вы думаете на эту тему?

очень сильно похоже на то, что из-за большого значения UNIFORM в 20Mb, которое я задал для нового табличного пространства во время апгрэйда, даже мелкие таблицы/индексы стали занимали в исходной системе не менее 20Mb. Далее, когда я сделал экспорт(для конвертации в Unicode), в параметрах хранения уже каждой таблицы(а не табличного пространства PSAPSR3!) прописалось начальное значение экстента = 20Mb, поэтому пространство у меня съедено не крупными сегментами, типа BKPF, а разной мелочью, но этой мелочи в штуках очень много и поэтому по топам я ничего найти не могу... но это только предположение... как эту идею проверить? и как это лечится?

Ну в общем где-то так. То есть Вы правы в своих выводах. Проверить можно - через тот же Oracle Enterprise Manager . Удачи!

Да кстати у SAP - все рабочие tablespace (кроме SAPTEMP) созданы с опцией Automatic Allocation

what is the method to change EXTENT MANAGEMENT LOCAL UNIFORM to EXTENT MANAGEMENT LOCAL AUTOALLOCATE?

http://www.dba-oracle.com/t_tablespace_ ... locate.htm

Changing from "extent management uniform" to "extent management autoallocate". When you specify extent management uniform, you specify the extent size yourself:

create tablespace fred extent management uniform size 10m;

With "extent management autoallocate, Oracle determines the optimal extent sizes:

create tablespace fred extent management autoallocate;

there is no "alter tablespace" syntax for changing extent management from uniform to autoallocate. Hence, you must re-define the tablespace with Oracle data pump to change the extent management:

- Backup the tablespace
- Export the tablespace data
- Drop and re-allocate the tablespace
- Import the tablespace