Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Дефрагментация и шринк табличного пространства  [new]
mefman
Member

Откуда:
Сообщений: 3173
tru55
Генерация текстов для SQL*Plus

Или тоуда. Или можно обернуть в PL-ку с execute immediate. Вы'ж программист :)
16 сен 15, 09:43    [18154521]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
Спасибо за ответы!
16 сен 15, 14:03    [18156068]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
roadster
Member [заблокирован]

Откуда: "Церковь тяжеловооружённого Христа" ©
Сообщений: 52495
GrayMagellan
Спасибо за ответы!
всё равно место кончится рано или поздно, как не переупаковывай.
совет про ограничение размеров и мониторинг мне понравился больше всего (после шринка конечно).
16 сен 15, 15:34    [18156747]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
roadster
GrayMagellan
Спасибо за ответы!
всё равно место кончится рано или поздно, как не переупаковывай.
совет про ограничение размеров и мониторинг мне понравился больше всего (после шринка конечно).


С мониторингом я тоже согласен - он в обязательном порядке должен использоваться, причем желательно как проактивное средство. Я вроде видел возможность настроить в EM различные пороги срабатывания алертов на место на диске. Это будем рассматривать как основной метод. А с ограничением размера - тут надо подумать. Если мониторингом не пользоваться или игнорировать его, то место в файле базы данных (если он ограничен) или на диске (если файлы не ограничены, как у нас) рано или поздно кончится, и опять встанет вопрос организации пространства для хранения данных. Будем его решать - шринковать, резать, бэкапить, в конце концов, возможно придется диски покупать.
17 сен 15, 12:08    [18159999]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
Смотрите какой ответ мне на этот SR дала тех. поддержка Оракла (а я эту проблему оформил и у них):

- It seems the issue is too close to 'REORGANIZE' Of Tablespace Fails With Error Space Header 'TYPE OF SEGMENT IS NOT SUPPORTED' ( Doc ID 292638.1 ), When a tablespace is converted to from dictionary to local management, 'SPACE HEADER' segments are created. 'SPACE HEADER' segments are the extents bitmap at the top of the locally managed tablespaces and they do not follow the normal rules of the extents.

- The EM reorganize translator does not support 'SPACE HEADER' and hence displays the error that this 'type of segment is not supported'.

- The space header segment contains the extent bitmap and is allocated during the migration of the tablespace. Once the segment has been created it can neither be dropped nor changed.
These segments are for Oracle internal space management for the tablespace itself as the data dictionary will not handle it anymore as it was with dictionary managed tablespaces.

- For resolving these errors :

- Perform the reorganize of the objects in these tablespaces directly at the object level.
- There is no need to move space header segment/s in the move of the objects, just move the objects (tables, indexes etc). The new locally tablespace where the user objects (tables, indexes etc) are moved contains its own SPACE HEADER segments.


Что за чушь-то? Почему они решили, что команда
CREATE BIGFILE TABLESPACE "DELETEME" DATAFILE '/storage1/oracle/oradata112/EPMTEST/deleteme01.dbf' SIZE 10M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
приводит к конвертации ТП из словарного в локально управляемое?! И вообще, о чем это они? Инстанс базы данных был сразу поднят из дистрибутива 11.2.0.3.0 - ни о каких апгрейдах и речи быть не может. А, насколько я знаю, если ТП SYSTEM было создано локально управляемым, то и все остальные ТП тоже создаются локально управляемые. Получается из этой фразы, что инструмент EM "Reorganize Objects" не умеет реорганизовывать локально управляемые ТП?
17 сен 15, 12:15    [18160049]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
А еще вопрос уважаемому сообществу - можно ли для перемещения объектов не создавать отдельное ТП, а использовать системное временное TEMP?
17 сен 15, 12:46    [18160319]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
По результатам проведенного эксперимента сам себе дам ответ - нет, нельзя.
17 сен 15, 12:58    [18160418]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
butya
Member

Откуда:
Сообщений: 17
Можно просто
ALTER TABLE DELETEME.TEST1 MOVE
если я правильно поняла ваш вопрос
17 сен 15, 16:09    [18161820]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
tru55
Member

Откуда: СПб
Сообщений: 19790
butya
Можно просто
ALTER TABLE DELETEME.TEST1 MOVE

Но это не гарантирует перенос таблицы в начало сегмента

Сообщение было отредактировано: 17 сен 15, 16:36
17 сен 15, 16:13    [18161845]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
butya
Member

Откуда:
Сообщений: 17
tru55,
была бы вам очень признательно, если бы вы объяснили почему так, или ткнули где почитать.
Спасибо
17 сен 15, 16:30    [18161937]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
tru55
Member

Откуда: СПб
Сообщений: 19790
tru55
butya
Можно просто
ALTER TABLE DELETEME.TEST1 MOVE

Но это не гарантирует перенос таблицы в начало сегмента

Пардон, не сегмента, а data file
17 сен 15, 16:36    [18161971]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
roadster
Member [заблокирован]

Откуда: "Церковь тяжеловооружённого Христа" ©
Сообщений: 52495
GrayMagellan
По результатам проведенного эксперимента сам себе дам ответ - нет, нельзя.
а почему нельзя понимаешь?
GrayMagellan
опять встанет вопрос организации пространства для хранения данных. Будем его решать - шринковать, резать, бэкапить
я правильно понимаю, что рассматривается вариант забэкапить данные, затем заделетить например данные за несколько предыдущих лет, шринкнуть и работать дальше?
подход конечно не нов, но
GrayMagellan
диски покупать
гораздо проще и даже дешевле для бизнеса.
посмотрите стоимость мегабайта уже в конце концов.
17 сен 15, 16:37    [18161978]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
roadster
посмотрите стоимость мегабайта уже в конце концов.


Вопрос не в стоимости мегабайта или одного/нескольких жестких дисков - они действительно стоят копейки, особенно для крупных компаний. Проблема в том, что для того, чтобы их купить, надо было в предыдущем закупочном году подать в Бюджетное Управление заявку на их закупку, и если я с пеной у рта докажу необходимость их покупки и они утвердят эти расходы в Бюджете следующего года, то я имею полное право пойти с этими бумагами в Закупочное Управление. И если я докажу (опять же, с пеной у рта) необходимость их покупки и они утвердят эту закупку в Годовой Комплексной Программе Закупок Компании на следующий год, то я жду, когда наступит следующий год, Закупочное Управление объявит открытый конкурс на право продать нам эти диски, их выиграет какой-нибудь Участник, и далее Договорное Управление будет с ним еще пол-года заключать договор (а я с пеной у рта буду их пинать, чтобы они шевелились быстрее). Только тогда, когда договор будет заключен и Подрядчик сможет отгрузить мне эти диски, а Финансовое Управление оплатит ему их, я, счастливый и довольный, побегу втыкать их в сервер.
22 сен 15, 17:23    [18181699]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
А по поводу тех. поддержки Oracle в результате полуторанедельных консультаций удалось выяснить, что инструмент Reorganize в Enterprise Management Database Control версии 11.2.0.3 не может дефрагментировать табличные пространства с признаком BIGFILE. В следующем SR мы обсуждаем вопрос, какая версия Oracle Database старше 11.2.0.3 может это делать. Ну а я упражняюсь в написании ручного скрипта по переносу объектов.
22 сен 15, 17:26    [18181728]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
... по схеме, предложенной уважаемым mefman в посте 18152581
22 сен 15, 17:28    [18181750]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
roadster
Member [заблокирован]

Откуда: "Церковь тяжеловооружённого Христа" ©
Сообщений: 52495
GrayMagellan
Проблема в том, что для того, чтобы их купить, надо было в предыдущем закупочном году...
всё понятно.
23 сен 15, 08:53    [18183267]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
И тут я уперся в ошибку
SQL Error: ORA-00997: неверное использование типа данных LONG (illegal use of LONG datatype) при попытке исполнить команду ALTER TABLE DELETEME.HFM_ERRORLOG MOVE TABLESPACE DELETEME2; :(. Интернет говорит, что ALTER TABLE MOVE TABLESPACE не поддерживает таблицы, имеющих такой тип данных в колонках.

Мать-перемать! Ну что же... все так трудно-то?! Почему в такой популярной, корпоративной, старой (аж 12 релизов уже выпустили!) базе данных, такой как Oracle Database нет элементарных средств дефрагментации базы данных?! Почему в MS SQL Server это делалось в пару кликов мышкой, а тут приходится так изголяться?! Ну если база данных позволила человеку создать такие таблицы, почему она не может их перемещать?! Что там такого непреодолимого (теоретически), что мешает передвинуть на диске кучу байт из одного места на диске в другое?!
30 сен 15, 17:02    [18216111]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
tru55
Member

Откуда: СПб
Сообщений: 19790
Думаю, что дело не в непреодолимости, а просто Oracle таким способом выдавливает тип LONG из употребления (он не рекомендован к использованию аж с 9 версии, если не с 8). Примерно так же поступает с dictionary managed tablespace (типа если system TS local managed, то и остальные тоже только local managed).
30 сен 15, 17:13    [18216203]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
Elic
Member

Откуда:
Сообщений: 29991
GrayMagellan
а тут приходится так изголяться?!
Потому что здесь это, как правило, не нужно. Но обезьяно-дба зачем-то придумали себе такое странное наполнение (не)рабочего времени.
Да и пенять надо не на СУБД, а на дебилов разработчиков.
30 сен 15, 17:14    [18216217]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
ArtNick
Member

Откуда:
Сообщений: 1227
tru55
Думаю, что дело не в непреодолимости, а просто Oracle таким способом выдавливает тип LONG из употребления (он не рекомендован к использованию аж с 9 версии, если не с 8). Примерно так же поступает с dictionary managed tablespace (типа если system TS local managed, то и остальные тоже только local managed).


Судя по
select * from sys.ALL_TAB_COLUMNS where data_type='LONG' and owner='SYS'

выдавливание идет крайне аккуратно
30 сен 15, 17:25    [18216341]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
Знаете, кого вы сейчас назвали
Elic
дебилов разработчиков.
? Команду разработчиков Oracle Hyperion. Так что эти претензии - не ко мне, если вы, конечно, под
Elic
обезьяно-дба
имеете ввиду людей, подобных мне, а именно таких людей, которые хотят быстро выполнить поставленную задачу, а не тратить, действительно, рабочее время на то, что система должна делать автоматом (или хотя бы полуавтоматом по команде человека). Особенно когда им этот функционал обещает разработчик Oracle Database. Это же не я в EM организовал этот Reorganize tool и не я установил правило, что табличные пространства только растут, не сжимаясь при удалении данных из них.

А тех. поддержка Оракла на мои сервис-риквесты "какого художника это не работает?!" сказала мне, что то, что я хочу от уже реализованного в EM функционала (см. скриншоты выше) - это "It's enhancement request, currently development team working on it" и "its enhancement request its fixed in the next major release"! Вот так! Т.е. если я правильно их понял, нормальные средства по дефрагментации базы появятся в Oracle Database только в следующем релизе 12-й версии базы. Весело и вкусно, Макдональдс! Только там хорошо всегда! Тра-ла-ла!
30 сен 15, 17:36    [18216414]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
Да, еще в команду этих горе-специалистов вы забыли добавить разработчиков жестких дисков, которые забыли проконсультироваться с Oracle, и не сделали в своей продукции бесконечное дисковое пространство.
30 сен 15, 17:41    [18216445]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
Elic
Member

Откуда:
Сообщений: 29991
GrayMagellan
? Команду разработчиков Oracle Hyperion.
Ты погугли. Там от оракла в основном только наклейка.
GrayMagellan
не я установил правило, что табличные пространства только растут, не сжимаясь при удалении данных из них.
Не ты, а те самые недоразработчики, продолжением которых приходится становиться тем самым …-дба. Монстры хорошими не бывают.

И вообще, тебе с твоими прекрасными отношениями с поддержкой не пристало плакаться в форумы.
30 сен 15, 18:02    [18216597]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
Elic,

тех. поддержка Оракла в 90% случаев не может решить проблемы, которые им заявляешь. Поэтому приходиться плакаться везде, где только можно. И зачастую советы снаружи дают более толковые, чем внутри.
30 сен 15, 18:15    [18216647]     Ответить | Цитировать Сообщить модератору
 Re: Дефрагментация и шринк табличного пространства  [new]
GrayMagellan
Member

Откуда:
Сообщений: 188
Ладно... Попробую в своем скрипте пока обойти мимо те таблички, имена которых выдаст запрос вида
select * from sys.ALL_TAB_COLUMNS where data_type='LONG' and owner='DELETEME'


Спасибо ArtNick за пост 18216341!
30 сен 15, 18:42    [18216769]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить