вообщем сказать что у нас дрянная ситуёвина, ничего не сказать!

Короче наш поставщик тяжёлой дури (зачёркнуто) софта для бугалтерии, с которым никто ничего поделать не может ( даже со скриптами его крайнего апедейта! ;-) ) и отказаться так просто от его услуг тоже не вариант, присылает такую "прелесть":




SomeSchema.SomeTbl состоит всего из одного поля REL (Varchar2(4000) )

("жесть как она есть!"(с)) Дальше больше: поскольку наша продуктивка с blocksize 4 k, то ясное дело огребаем:

авторORA-01450: maximum key length (string) exceeded tips

начальство приняло решение что мол "ночью полетим"(с) (зачёркнуто) что я должен спасти базу, а именно начальство хочет вылить всё из дефолтного Tablespace (так около 90% данных) через ExpDp создать её с опцией 8k и залить всё обратно через ImpDb.... No comments.... :-(

Без посадки переметра db_8k_cache_size в не 0 (мы посадили на = 4 G ) TS c альтернативным blocksize на создашь!
( огребём автор"ORA-29339: tablespace block size 16384 does not match configured block sizes")
Но поскольку память у нас управляется вот так: sga_target = 6 G
то думаю это изменение ( db_8k_cache_size = 4 G ) повлиять ни на что не должно, ибо это атавизм в данном случет, так ведь?

Какие ещё могут быть побочные эффекты данного "хакерства для несчастных"? Вы можете что то передвидеть плохое, спецы? (я лично пока нет)....

есть, вроде всё идёт пока ок на ней. Но это пока....

ну они как бы названы, не? ( ORA-01450: maximum key length (string) exceeded tips )

начальство говорит, что их не было. .... Как гртся "за что купил" ........

ага! Спасибо большое! Вот этот то моментик я как раз и подзабыл, ибо много лет с этим не сталкивался.... Ну ок. Если в новом TS (который мы создали с blocksize = 8 k) живут около 90% данных, то две третих (66%) SGA ему - этому новому buffer cache, возможно и не грех отдать, или нет...?

хэх! )) Было бы неплохо ))) Да только скрипт то от этих ухарей тупо падает на месте попытки создания инекса, увы! ;-)

нннннетттт блллл(ин) ! :-) Скрипт сам создаёт эту тупую табличку и пытается тут же навешать PK

Доступа к скрипту у нас _НЕТЪ_ !!! :-(

некоей 3й фирмой, через какой-то там их Upgrade-tool! :-(
"так и живём"(с)

яволь! :-)

это Вы вообще о чём, развейте мысль плиз)))

чушь какая то. Instead OF триггер? Дык это вообще-то про вьюхи, т.e. тут вообще "не в кассу"

Может DDL-триггер имелся ввиду? Ну в нём можно например в лог что-то написать и т.п., но чтоб он подменял(!) исполняемую DDL-ину?! такого я не знаю )))

Кстати, тестирую я этот свой экшн на похожей базе 12с, а боевая-продуктивка она 11g, блин горелый! )))

ха ха! Вот чёрт! ;-) Действительно работает! (а гугл у меня и вправду сегодня тормозит чет!!! Честно! )) )

Жаль что нет (пока) “INSTEAD OF ALTER” , только “INSTEAD OF CREATE”, да? :-(

Вообщем в данной ситуации это было бы решением! Сразу перенаправить в ддл-триггере создаваемую табелюську в 8k-tablespace, тогда и создание PK (следующей за CREATE TABLE командой: ALTER TABLE) пройдёт не вздрогнув, правильно?

Но тупо будет, если в этот, или в один из следующих апгрейдов эти господа захотят создать подобный говно-индекс на уже(!) существующей (в дефолтном 4k ТS-е) таблице... Ну тогда сию печаль-таблицу придётся руками переселять в 8-к. Красивее варианта лично я пока не вижу.... а вы-уважаемые?

Или таки сразу всё чохом лучше сейсас переселить в 8-к, чтоб потом не парицца? Как бы вы поступили?

ну дык и новые таблицы юзверя создались бы не в том TS в котором лежат старые! Нафиг такая "пестрятина"))

пасибки! Буду знать.

ну тогда это, как минимум, ещё одно лишнее TS для такого рода индексов. Да и потом, по каждому (в будущем возможному такому случаю) "мувить" руками отдельные элементы, это нежелательный manpower. (начальство у нас считает)

Короче, вопрос в заголовке таки пока положительно не отвечен, будем считать. Т.е. я исхожу из того что каких-то (опасных, критичных) побочек таки нет. Ок?

Ну и на этом всем спасибо за участие тогда. :-)

сорри, не совсем понял - что есть в данном случае "кривое значение"? (4k?). Так это базу полностью тогда пересоздавать надо. Очень затратное и рискованное мероприятие в нашем случае.


авторчто-то криво сделать и потом еще пару месяцев разыскивать пропавшие объекты/гранты/синонимы и прочее

что-то _конкретно_ тут можем сейчас криво сделать? Наш сценарий изложен и уже протестирован. По какому, на ваш взгляд, сценарию могут пропасть обьекты??? (cерьёзно не понимаю и серьёзно очень интересно было бы узнать/понять). Спасибо!