[ТЕМА ЗАКРЫТА]
23.10.2011 16:02
AlexeyF
 
oracle 10.2.0.4
база ЦО 85Гб
Подскажите ?
Есть табличка "SUPERMAG"."SMSPEC"
Решил оптимайзер прогнать -c=S и у меня уже какой раз это мероприятие заканчивается со словами
Gather stats... Table : "SUPERMAG"."SMSPEC"
Validating...
Запускаю, пару часов тишина, потом отваливается и всё.
SMSPEC не PARTITIONED

Вопрос как с этим жить, какие есть варианты Validating этой таблички сделать ?
23.10.2011 17:59
OlegON
 
Со связью что-то? Сделай alter table supermag.smspec move;
23.10.2011 18:01
Propil
 
Думаю, что вручную в SQL plus
Код:
ANALYZE TABLE "SUPERMAG"."SMSPEC" VALIDATE STRUCTURE;
24.10.2011 09:28
akonev
 
на относительно больших базах часто именно валидация SMSPEC задумывается надолго. я пару раз так и не дождался, потому что при этом база резко тормозила до невозможности работать, а время обслуживания заканчивалось, надо было хомячков запускать.

но вот именно то, что отваливается, это скорее всего связь.

рецепт, приведенный выше Propil - работает
24.10.2011 09:32
OlegON
 
И все же я бы предложил сделать move и дождаться хоть раз, чтобы отработало. У Propil не та валидация, что делает оптимизатор.
24.10.2011 09:59
akonev
 
понятно, что не та валидация. зато отрабатывает быстро и позволяет сразу снова запускать оптимайзер в работу.

но когда по срокам снова придет время спекам анализироваться - могут снова заткнуться на валидации. или когда оптер запустится с командой -c=S

так что оставлять все как есть - тоже не резон.
24.10.2011 10:02
OlegON
 
не могу пока сказать, что так задерживает на валидации, все мои подконтрольные БД, среди которых есть минимум парочка побольше указанной в пару раз, отрабатывают нормально.
24.10.2011 12:51
AlexeyF
 
Меня то интересовало именно что бы оптимизатор доделал -c=S
только я столкнулся
24.10.2011 12:58
AlexeyF
 
Вот проблема отсутствия редактирования, случайно Ctrl+Shift нажал и сообщение неполное уехало :(
продолжаю:
только я столкнулся с тем, что когда идёт validate оптимайзера, пакеты в почтовике иногда вылетают с руганью на SMSPEC. Поэтому я эту процедуру (-c=S) запускать пробовал без нагрузки - в нерабочее время.
Ограничение на простой коннекта 260 сек. понимаю так, что этого не хватает ?
когда операция выполняется оптимайзером у него обмена нет никакого ?
Я конечно сделаю как предлагалось, но хочется всётаки чтобы оптимайзер доработал, не одна же SMSPEC в базе большая.
Кстати, подскажите, а имеет смысл SMSPEC сделать PARTITIONED, или сжать её, с точки зрения производительности что посоветуете ?
24.10.2011 13:04
akonev
 
большая она не одна, но утыкаются почему-то все именно в нее. и только в нее.

не знаю, где что у нее в мозгах перещелкнулось, но после ручной валидации у меня следующий прогон -c=S прошел нормально.
24.10.2011 13:24
AlexeyF
 
сделаю ручную, после того как сделаю move, потом уже прогоню =S
Жаль что это сделать можно будет только завтра вечером - сегодня база занята будет.
После move таблицы надо только индексы ребилдить или что ещё ? (а то давно я move не делал)
24.10.2011 13:27
OlegON
 
прогони -c=o, оно само индексы соберет...
24.10.2011 13:31
AlexeyF
 
Цитата:
OlegON прогони -c=o, оно само индексы соберет...
Так и сделаю, только может возникнуть ситуация с оптимайзером - 15 минут подождать, поэтому может и ручками кое что будет быстрее.
25.10.2011 17:26
AlexeyF
 
Сделал MOVE, потом индексы оптимайзером, потом оптимайзер -о=S и о чудо, SMSPEC отвалидейтился :)
Теперь над FFMAPREP думает...
26.07.2013 07:33
Stels
 
ситуация похожая:
база магазина
oracle 10.2.0.5 , win2003 32 bit

оптимайзер запускается с -c=о
и останавливается на
Код:
26.07.13 00:13:20 -- Gather stats... Table : "SUPERMAG"."SMCASHCHECKITEMS"
26.07.13 00:13:20 -- Gather...
26.07.13 00:49:54 -- Validating...
сделал
Код:
alter table supermag.SMCASHCHECKITEMS move;
отработало

снова запустил оптимайзер с -c=o
Код:
<skip>
25.07.13 23:03:00 -- Tables check...
25.07.13 23:03:04 -- **************************************************************
25.07.13 23:03:04 -- Gathering list of invalid indexes
25.07.13 23:03:06 -- Rebuilding of SUPERMAG.SMCCASHCHECKITEMS_PK :2 : 580Mb
25.07.13 23:09:16 -- Rebuilding of SUPERMAG.SMCASHCHECKITEMS_ART :1 : 383Mb
25.07.13 23:13:48 -- **************************************************************
25.07.13 23:13:48 -- Partitions and subpartitions state check
25.07.13 23:13:49 -- **************************************************************
25.07.13 23:13:49 -- Gathering list of invalid index partitions
25.07.13 23:13:49 -- **************************************************************
25.07.13 23:13:49 -- Gathering list of invalid index subpartitions
25.07.13 23:13:50 -- Index rebuild completed...
25.07.13 23:13:50 -- **************************************************************
<skip>
26.07.13 00:00:04 -- Table : SUPERMAG.SMCASHCHECKITEMS Size : 728Mb
26.07.13 00:00:05 -- Standart optimization... 14
26.07.13 00:02:26 -- **************************************************************
26.07.13 00:02:26 -- Gathering list of invalid indexes
26.07.13 00:02:28 -- Rebuilding of SUPERMAG.SMCCASHCHECKITEMS_PK :2 : 582Mb
26.07.13 00:08:40 -- Rebuilding of SUPERMAG.SMCASHCHECKITEMS_ART :1 : 379Mb
26.07.13 00:13:19 -- **************************************************************
26.07.13 00:13:19 -- Partitions and subpartitions state check
26.07.13 00:13:19 -- **************************************************************
26.07.13 00:13:19 -- Gathering list of invalid index partitions
26.07.13 00:13:20 -- **************************************************************
26.07.13 00:13:20 -- Gathering list of invalid index subpartitions
26.07.13 00:13:20 -- Index rebuild completed...
26.07.13 00:13:20 -- **************************************************************
26.07.13 00:13:20 -- Gather stats... Table : "SUPERMAG"."SMCASHCHECKITEMS"
26.07.13 00:13:20 -- Gather...
26.07.13 00:49:54 -- Validating...
и опять за 6 часов конца операции не дождался ...

руками пока не пробовал
Код:
ANALYZE TABLE "SUPERMAG"."SMCASHCHECKITEMS" VALIDATE STRUCTURE;
а алерте:
Код:
Thu Jul 25 22:49:20  2013
Some indexes or index [sub]partitions of table SUPERMAG.SMCASHCHECKITEMS have been marked unusable
.........................
Fri Jul 26 00:02:26  2013
Some indexes or index [sub]partitions of table SUPERMAG.SMCASHCHECKITEMS have been marked unusable
что можно сделать?
26.07.2013 07:44
OlegON
 
Предлагаю еще раз прогнать. Предполагаю проблемы со связью.
26.07.2013 07:52
Stels
 
прогонял уже несколько раз - ситуация не меняется ..
оставить на дольше не могу - есть только ночь..

проблему со связью исключаю, т.к. запускаю удалённо из дома
и на всю ночь связь с сервером не прерывается
26.07.2013 07:52
whitewizard
 
а индекс перестроить не получается?
26.07.2013 07:55
OlegON
 
Дело не в индексе, валидация не проходит, тогда попробуй все же то, что "руками не пробовал". Можно днем. Если удаленный доступ через RDP, например, то он достаточно лоялен к обрывам связи - переподключается просто. Кроме того, в пределах города связь может и не рваться.
26.07.2013 07:57
Stels
 
я так понимаю оптимайзер это сам прекрасно делает
Код:
25.07.13 23:03:06 -- Rebuilding of SUPERMAG.SMCCASHCHECKITEMS_PK :2 : 580Mb
25.07.13 23:09:16 -- Rebuilding of SUPERMAG.SMCASHCHECKITEMS_ART :1 : 383Mb
или попробовать руками?
Код:
alter index ...rebuild
?
26.07.2013 07:58
whitewizard
 
Вот, если индекс кривой, то его перестроение и покажет, где собака порылась. Разве не так?
26.07.2013 08:00
Stels
 
попробовать
Код:
ANALYZE TABLE "SUPERMAG"."SMCASHCHECKITEMS" VALIDATE STRUCTURE CASCADE;
или
Код:
ANALYZE TABLE "SUPERMAG"."SMCASHCHECKITEMS" VALIDATE STRUCTURE ;
?
26.07.2013 09:34
OlegON
 
Цитата:
whitewizard Вот, если индекс кривой, то его перестроение и покажет, где собака порылась. Разве не так?
неа, индекс сначала надо сделать инвалидным или смувить табличку (лучше второе). в противном случае построение индекса сводится к копированию текущего.
27.07.2013 07:48
OlegON
 
Я вчера, видимо, подустал уже... Самое быстрое и правильное, конечно, не validate гонять по кругу, а сделать, как написано тут: Увеличение доступности БД Oracle
В этом случае валидация пройдет в сотни раз быстрее и сразу всей базы.

OlegON:
Тему закрываю, если надо будет продолжить - заведите новую
Опции темы


Часовой пояс GMT +3, время: 07:17.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.