Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Oracle |
![]() ![]() |
Топик располагается на нескольких страницах: 1 2 3 4 5 [все] |
tim128 Member Откуда: Сообщений: 145 |
Разбирался с большим количеством chained rows в статистике системы, обнаружил что их продуцирует картографический сервер дергая таблицы с пространственными (spatial) индексами. При создании такого индекса создается вторичная (secondary) таблица с именем типа MDRT_32C40$. При построении такого индекса порядка 33% строк оказываются chained. Размер блока 8К, строка такой таблицы содержит два поля number и inline blob. Blob размером всегда 1968 байт. PCTFREE=2 и как поменять его я найти не смог. Два вопроса: 1. Можно этим таблицам сделать alter table move для ликвидации chained rows или это черевато? 2. Что можно сделать для того чтобы chained rows в таких таблицах не возникали в последствии? Например можно ли изменить PCTFREE такой таблице через ALTER TABLE а не через ALTER INDEX? |
9 авг 13, 09:20 [14684893] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
Только это migrated а не chained. |
9 авг 13, 10:46 [14685450] Ответить | Цитировать Сообщить модератору |
tim128 Member Откуда: Сообщений: 145 |
Конечно. Я трактую migrated rows как частный случай chained rows. В статистике отображается количество chained rows fetch. Я анализирую эти фетчи и вижу что данные строки вполне могли бы поместиться в один блок и делаю вывод, что это тот случай, который принято называть "migrated rows". В противном случае стразу можно было смириться. |
||
9 авг 13, 11:16 [14685725] Ответить | Цитировать Сообщить модератору |
xtender Member Откуда: Мск Сообщений: 5749 |
tim128, выскажу имхо:
|
||||
9 авг 13, 12:03 [14686095] Ответить | Цитировать Сообщить модератору |
tim128 Member Откуда: Сообщений: 145 |
Попробовал alter table move. На свой страх и риск. Индекс сломался. Хорошо ALTER INDEX REBUILD помог. Попробовал alter table pct_free=10. Но поскольку MOVE не работает чтобы перестроить таблицу приходится запускать ALTER INDEX REBUILD а он опять сбрасывает в pct_free=2. Может еще идеи будут? |
9 авг 13, 14:52 [14687375] Ответить | Цитировать Сообщить модератору |
xtender Member Откуда: Мск Сообщений: 5749 |
tim128, sdo_rtr_pctfree? |
9 авг 13, 15:36 [14687712] Ответить | Цитировать Сообщить модератору |
Rb-Sr Member Откуда: Сообщений: 296 |
tim128, При построении таких индексов можон указывать параметр work_tablespace, весь "временный мусор" во время постоения будет там |
9 авг 13, 15:41 [14687754] Ответить | Цитировать Сообщить модератору |
tim128 Member Откуда: Сообщений: 145 |
Нет, этот параметр регулирует резерв пространства внутри этого blob-a, который хранится во вторичной таблице. |
||
12 авг 13, 13:26 [14696373] Ответить | Цитировать Сообщить модератору |
tim128 Member Откуда: Сообщений: 145 |
Создадутся таблицы в другом табличном пространстве, но как это повлияет на chained/migrated rows? К тому же work_tablespace судя по доке влияет не на вторичную таблицу с телом индекса, а на другие дополнительные таблички. |
||
12 авг 13, 13:31 [14696409] Ответить | Цитировать Сообщить модератору |
xtender Member Откуда: Мск Сообщений: 5749 |
tim128, nfr ghj nj b htxm ;t |
12 авг 13, 13:56 [14696638] Ответить | Цитировать Сообщить модератору |
xtender Member Откуда: Мск Сообщений: 5749 |
|
||||
12 авг 13, 13:57 [14696642] Ответить | Цитировать Сообщить модератору |
tim128 Member Откуда: Сообщений: 145 |
xtender, Нет речь о том что эти блобы размазываются по двум блокам |
12 авг 13, 15:38 [14697516] Ответить | Цитировать Сообщить модератору |
tim128 Member Откуда: Сообщений: 145 |
Обратился в техподдержку. Ответили, что легального способа нет, но посоветовали создать DDL триггер на создание таблиц, который подправляет значение PCTFREE. Операция прошла вполне удачно, при значении pctfree=25 все chained_cnt ушли при этом количество blocks даже не изменилось |
14 авг 13, 11:58 [14706811] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
tim128, Приветствую. С вашего позволения, подниму тему еще раз. У самого сейчас такая же ситуация... Но только, видимо, у нас немного критичнее ситуация. Есть вопрос один - сколько полей в тех таблицах, которые "мигрируют" (или блоки которых сцепляются). На вскидку примерно?... У меня получается, что количество полей сейчас уже равно 484 штуки на таблицу эту (слава богу, она одна "глючит")... При этом вот с таким распределением: Типы полей и их количество в таблице:
Собрал статистику (ручками) по распределению строк в блоках:
При этом окружение следующее: С PCTFREE баловались месяц-два назад. Увеличили его, таблицу мувили. На какое-то время это помогло, но только частично. Сейчас очень интересную статистику иногда база показывает... Как ее трактовать, сложно подумать... (точнее SpootLight показывает.): см. приложенный файлик. К сообщению приложен файл. Размер - 60Kb |
||||||||||||||||||||||||||||||||||||||||||||
24 сен 13, 13:27 [14877164] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Да, в предыдущем сообщении не видно, но на "логических чтениях" (где красным подсвечено) там надпись идет: иногда 10%, а иногда и 1750% of rows fetches "continue" to another block При этом сами "логические чтения" при физических чтениях в 6000blks/s не поднимаются выше 12000blks/s В среднем "логические чтения" около 50000blks/s колеблются, но часто ругается на rows fetches "continue" to another block Максимально "логических чтений" было замечено со скоростью 117000blks/s. Кто-то что-то подсказать может? Создавать TAbleSpace с размером блока в 16k и туда таблицу мувить, только так?.. Или что в таких случаях делают? (п.с. не предлагать "денормализацию" или "нормализацию" - полей сколько есть, столько есть - это никак не переделаешь... Размеры CLOB обычно от 500 байт до 50Кб, не больше. Но обычно не больше 512Кб. |
24 сен 13, 13:36 [14877221] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Версия Oracle SE1 11g R2, если что. |
24 сен 13, 13:37 [14877229] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||
24 сен 13, 13:44 [14877285] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
wurdu, Проблема в том, что производительность упала весьма существенно. Как пример, есть 40 штук контекстных индексов (Oracle Text) - которые при генерации активно юзают ввод-вывод + процессор. Так вот процессор ОК - не больше чем не 10% загружен. А вот этот самый IO глючит (о чем SpootLight и показывает). Не смотря на то, что буферный кэш весьма нормальный для данного объема данных. Мы имеем "тормоза". Для примера год назад, эти 40 контекстных индексов перестраивались 35 минут. А сейчас перестраиваются почти 7 часов. (данных было 1,8 млн, сейчас 2+ млн.) Плотность (заполненность) данных выросла, естественно, процентов на 30. (от чего и блоки "сцепленными" видимо стали). Ну и плюс количество полей: +50 примерно получилось. |
24 сен 13, 14:00 [14877379] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
wurdu, При всем уважении, просьба не советовать "собрать статистику" - она собирается. Не советовать "раскидать данные по другим таблицам" - это невозможно сделать в данной архитектуре. И не советовать что-то типа "возьмите запрос ЧЧЧ" и трассировку с него сделайте. Смысла в этом нет - тут проблема на уровне "организации данных", "администрирования СУБД", "табличных пространств", ввода-вывода и т.д. Проблема уже локализована - страдает логический ввод-вывод. Точнее "логические чтения". Вот когда обращения идут исключительно к "горячим блокам" (данным, которые в кэш БД хранятся, мы видим что-то типа как на картинке. При этом там "красное" - это "47% of rows fetches "continue" to another block". К сообщению приложен файл. Размер - 32Kb |
24 сен 13, 14:07 [14877418] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Иногда наблюдаются вот такие вот действия: К сообщению приложен файл. Размер - 76Kb |
24 сен 13, 14:07 [14877422] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Или вот такие вот: К сообщению приложен файл. Размер - 67Kb |
24 сен 13, 14:08 [14877426] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Просто цифры почти в 10000%of rows fetches "continue" to another block, думаю, говорят за себя... Но это не предел, однако... Когда эти самые "rows fetches "continue" to another block" растут - запросы начинают неимоверно тормозить...на определенных выборках данных. Куда копать? Что в таких случаях делают?.. п.с. я понимаю, что буферный кэш спасает частично эту ситуацию, т.к. иначе все в "физические чтения" упиралось бы. Но тем не менее, избавляться от этих "continue fetches" нужно ведь. Потому что "тормоза" весьма серьезно нарастают в БД. К сообщению приложен файл. Размер - 27Kb |
24 сен 13, 14:13 [14877446] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
sergey.semka, я предлагаю не смотреть на показания Spotlight потому что они не несут никакой смысловой нагрузки. Опять же, насколько я вижу, он подменяет Оракловые названия статистик на какие-то самопальные и я могу лишь предположить что за rows fetches "continue" to another block скрывается "table fetch continued row". Переводить проблему из конкретной и понятной в русло "организации данных", "администрирования СУБД", "табличных пространств", ввода-вывода и т.д" я бы не стал. Поэтому предлагаю для начала сделать тесткейс на примере запроса который тормозит и показать по нему трассировку и статистику по "table fetch continued row". Потому как с таким кол-вом колонок проблемы могут быть разного характера. Я описывал уже в свое время одну из них: Индекс вместо полного сканирования. |
24 сен 13, 14:53 [14877719] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
Да, и если проблема действительно как тебе кажется носит глобальных характер, то покажи AWR за проблемный период. Но только не Spotlight. Про перестройку индекса пример уже интересный. Просто fullscan по таблице не тормозит? |
24 сен 13, 15:00 [14877768] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
wurdu, Нету AWR и не будет.... потому что данный экземпляр "животной фауны" - это Oracle SE1 11g R2... Тут нет ни Enterprise manager, ни AWR... Максимум это от Spootlight показания и селекты из каки-то системных View. (п.с. таблички что в первом посте прислал - это А вообще в моем первом посте не ясно что ли, что записи некоторые располагаются на 11 разных блоках(!) вместо одного. Уж куда дальше проблему то описывать?.. Понятно, что тормоза много от чего могут быть. Но тут что "подменяет spootlight" Тоже хотелось бы узнать. Вообще он свою среднюю какую-то ведет... сколько было каких чтений и говорит, что за последние 30 секунд выборки на 70 тысяч процентов превышают по показателю Continued fetch то, что было у него "средним значением"... Он тоже не тупой, он калибруются по статистикам из БД постоянно. ps: В "чудесную" табличку CHAINED_ROWS (для тех кто знает) попало 1'851'080 из 2'338'804, что соответствует 79,14% всей "проблемной" таблицы. |
24 сен 13, 15:25 [14877935] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
wurdu, На сколько я знаю, при количестве полей >255 Oracle всегда делает "chaining rows"... Только вот они "intra-block" или на несколько блоков - тут уже другой вопрос... У нас получается, что количество полей далеко за 255+... К тому же дампирование "блоков" по записям показало, что записи располагаются в большинстве случаев на 2, 3, ... , 11 различных блоках, что, как мне кажется уже само говорит о "проблемах". Или я ошибаться? |
24 сен 13, 15:33 [14878020] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Что еще касается таблицы нашей. Нашел такие вот данные: "Segment IO" на эту таблицу:
К сообщению приложен файл. Размер - 22Kb |
||||||||||||
24 сен 13, 15:42 [14878101] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Если нужны какие-то скрипты прогнать или какую-то еще статистику собрать - скажите, сделаю... Просто голова не достаточно квадратная... чтобы решить данную проблему. Помогите, если можете кто-нибудь... К сообщению приложен файл. Размер - 50Kb |
24 сен 13, 15:45 [14878134] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
И подобная картинка, но уже по Phisical IO/s К сообщению приложен файл. Размер - 44Kb |
24 сен 13, 15:47 [14878147] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
И все же у меня подозрение складывается, что вот эти "продолженные чтения" пусть даже "логические" и пусть даже из "буфера БД"... Очень сильно сказываются на выборки... т.к. база, вероятно, в табличные пространства даже в этом случае "бегает", не довольствуясь одним Кэшем... Я правильно мыслю? (или на обычные селекты она не должна никуда лезть... Где она вообще узнает, на сколько это "свежий блок"?.. всегда ли Oracle в табличные пространства на "холодные" блоки смотрит? и в Undo-сегмент?... Или она по кэшу сразу может "опознать" что блок содержит последние, нужные ей данные и даже за "сцепленными" она по кэшу бегать будет?... ВОт мне кажется загвостка тут как раз в работе с кэшем... и что-то мне подсказывает, что на эти "сцепленные блоки" он не может нормально из кэша смотреть... а куда-то за каждым "сцепленным" постоянно лазиет... толи в табличное пространство само, убедиться, что блок никто не изменил, то ли в Undo... Потому что когда затрагиваются "кэшированные" блоки, "не сцепленныых строк" - запросы "летают"... А как только "сцепленные строки" задеваются, не смотря на то, что буферный кэш размером с саму таблицу эту главную, и даныне весьма часто "поднимаются запросами" - складывается подозрение, что oracle все равно вынужден бегать и смотреть куда-то кроме самого кэша... Может кто ссылко скинет, почитать, как там дела обстоят... или расскажет?...как Oracle в таком случае работает с кэш, если есть "сцепленные строки" в разных блоках расположенные... |
24 сен 13, 16:12 [14878361] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
sergey.semka, Видимо Том Кайт форум не читает, а без него тут никто ничего не может сказать... Блин, ну хоть мысли у кого какие есть? |
24 сен 13, 22:14 [14879899] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
sergey.semka, Видимо Том Кайт форум не читает, а без него тут никто ничего не может сказать... Блин, ну хоть мысли у кого какие есть? |
24 сен 13, 22:20 [14879916] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||
25 сен 13, 01:32 [14880260] Ответить | Цитировать Сообщить модератору |
dbms_photoshop Member Откуда: sqlmdx.net Сообщений: 5151 |
Можешь конкретизировать вопрос что именно непонятно? Вкратце, если блок есть в кеше, то Оракл не будет читать его с диска (за исключением багов). В общем виде логика описана здесь: http://jonathanlewis.wordpress.com/2009/06/12/consistent-gets-2/ Более подробно (но мало текста): http://www.juliandyke.com/Presentations/TransactionInternals.ppt Для получения согласованной версии может возникнуть необходимость лезть в undo. Работает, учитывая xid, scn, uba. Здесь роль играет организация undo. Детали All About Oracle's In-Memory Undo (06-May-2009) PRESENTATION. Если интересует, что именно читается для получения согласованной версии - event 10200. Примерно как здесь: 14673064. По поводу этого всего можно не особо париться, если допустить, что среда однопользовательская. На самом деле можно долго ковыряться, но при таблице с 400+ столбцами проблема, думаю, будет перманентной. Единственный банальный "редезайн" сдвинуть колонки с большим процентов null'ов в конец. А почему невозможно вертикально разделить таблицу? |
||
25 сен 13, 02:19 [14880280] Ответить | Цитировать Сообщить модератору |
chain
Guest |
|
||
25 сен 13, 02:21 [14880281] Ответить | Цитировать Сообщить модератору |
_Nikotin Member Откуда: СПб Сообщений: 2965 |
sergey.semka, откати статистику на то время когда всё было нормально |
25 сен 13, 02:35 [14880285] Ответить | Цитировать Сообщить модератору |
chain
Guest |
_Nikotin, Сегмент таблицы он к тому времени, без потери данных, к сожалению, "откатить" не сможет. |
25 сен 13, 02:39 [14880287] Ответить | Цитировать Сообщить модератору |
Вячеслав Любомудров Member Откуда: Владивосток Сообщений: 18509 |
Ну и DDL таблички бы не помешал А то там небось до кучи еще и LOB ENABLE STORAGE IN ROW |
25 сен 13, 02:50 [14880292] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
Смысл в том, что нельзя априори считать что проблема с производительностью связана с chainded/migrated rows. Потому как не предоставлено никакой информации подтверждающей это. Если, например, план запроса поехал, то мы увидим возросший LIO, ну и статистики "table fetch continued row" также вырастут. Но это не значит что LIO вырос потому что chained/migrated rows. Да, в случае с migrated/chained rows требуется больше lio при обращении по rowid, а при chained fullscan начинает работать одноблочными чтениями. Но не факт что это создает проблему в данном случае. Если есть конкретный запрос / запросы то надо показать трассировки по ним + планы + статистику по "table fetch continued row" . Если проблема проявляется периодически с проседанием производительнсти, то нужен statspack + планы просевших запросов. |
25 сен 13, 03:07 [14880298] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Ну конечно, они "IN ROW" все... Только у них заполняемость разная, какие-то содержат 50 байт информации, какие-то 500 байт, какие-то 4Кб, максимум 50Кб (но это редкость). Часть вообще пустых. Просто они все поисковые... и все такое. По этому их выносить "OUT ROW" будет очень "дорого" на запросах, т.к. они постоянно запрашиваются, правятся, в поисковых запросах участвуют. |
||
25 сен 13, 14:37 [14882699] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Ну "распределение строк по блокам" можно только запросами с "дампированием" блоков, на которых располагается строка делать... Эту статистику только ручками можно собрать. Я о ней говорил. |
||||
25 сен 13, 14:38 [14882708] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Статистика всегда собирается новая, автоматически обновляется... А то время, когда "все нормально было" - тогда записей было меньше, полей было меньше, а самое главное "заполняемость строк" бала меньше... Так что вопрос излишний... |
||
25 сен 13, 14:39 [14882725] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
[quot dbms_photoshop]
Разрезать таблицу нельзя, т.к. с ней FORMS работает напрямую... И ему не объяснишь, что за вот той кучкой полей сходи туда-то... Редизайн по этому не получится...уже говорил об этом. По поводу "сдвинуть колонки с большим процентов null'ов в конец" - сложный вопрос. Потому что данные постоянно "доливаются" и "довбиваются"... от этого и происходит и миграция и сцепление... Как я понял, тут поможет исключительно перенос в табличное пространство с 16К... А за развернутый ответ спасибо. п.с. как работает Oracle с обычными блоками я знаю... просто тут такое подозрение возникло, что когда появляются "сцепленные строки" - вот именно за ними (или анализом их состояния) Oracle вынужден еще куда-то лезть... Ибо, зная, что данные "горячие" и подняты в кэш - для тех строк, которые "не сцепленны" - все летает... для "сцепленныех" не смотря на то, что все в кэш БД - начинаются какие-то бешенные тормоза... такое ощущение, что Oracle еще куда-то бегает за каждым "сцепленным" блоком строки... Или кэш блокирует постоянно, бегая в поисках этих "сцепленных блоков". В самом блоке есть информация, что с ним еще какой-то блок сцеплен и этот "сцепленный блок" тоже находится в буферном кэш, я про это? |
||
25 сен 13, 14:46 [14882785] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
При всем моем уважении к вам и вашему профессионализму... Повторюсь, у меня по распределению в данной таблице имеется как минимум 111 строк, расположенных на 11(!) разных блоках. И 500+ тысяч(!) строк, расположенных на 2 блоках... есть еще на 3 разных блоках и т.д. Это не означает, что есть "сцепленные строки"?... Я прекрасно знаю, что там "говнокод", что там "кривая структура таблиц", "кривыми руками и кривым софтом написанные запросы имеются"... и много-много-много еще прочего. Вот все, перечисленное не изменилось... оно еще с версии 8-го Oracle мигрирует из версии в версию... И на 11g R2 Standard Edition ONE все "весьма неплохо" работало до последнего времени. И особых проблем не было. Проблемы появились когда - появились эти "сцепленные" строки. И я не с потолка это взял. А смотрел Chained_rows, смотрел "продолженные чтения из статистики", ручками "распределение строк по разным блокам" собрал... и прочее... И на сколько я могу предполагать, проблема в этих самых "сцепленных" блоках. И у меня основной вопрос, что в таком случае делать, и может ли такая проблема снижать производительность, даже учитывая, что больАя часть данных в кэш базы данных поднимается и не сильно то вытесняется оттуда... Как-то так. В общем... Кто-нибудь вообще боролся с проблемами "сцепленных блоков" и прочим?... Об ошибках в ДНК архитекторов, разработчиков и программистов можете не рассказывать... Сам такие имел когда-то. Таблицу нормализовать или резать невозможно. Слишком много на это завязано. Задача встала в том, что с этим что-то нужно сделать. Ибо сейчас все это "тормозить стало". И вопрос стоит в том, что это дополнительными ресурсами "закрыть" или еще как-то. Вопрос стоит в "Экстенсивном методе развития", хотя это и не правильно. |
||
25 сен 13, 14:56 [14882882] Ответить | Цитировать Сообщить модератору |
Сергей Арсеньев Member Откуда: Сообщений: 4118 |
Не совсем. У Вас подход - напихать много маленьких строк в один блок. А потом при помощи update увеличить их длину. Попкорн. И чем больше пакет, тем больше из него будет вываливаться. При таком подходе вам pctfree в районе 90% нужен. |
||
25 сен 13, 15:12 [14883037] Ответить | Цитировать Сообщить модератору |
попкорн11
Guest |
Народ похоже тему не читает... у товарища таблица с 484 столбцами. |
25 сен 13, 15:15 [14883066] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Ну не 90... а 75 был сделан... месяца три еще назад =) |
||||
25 сен 13, 15:21 [14883115] Ответить | Цитировать Сообщить модератору |
Сергей Арсеньев Member Откуда: Сообщений: 4118 |
Причем с inline lob. По началу null. А потом ... И как тут не быть мигрантам и цепочкам. |
||
25 сен 13, 15:27 [14883162] Ответить | Цитировать Сообщить модератору |
Сергей Арсеньев Member Откуда: Сообщений: 4118 |
Сергей Арсеньев, Хотя конечно ~500 столбцов в одном блоке редко когда могут уместиться. Тут о 64K блоке с PCTFREE 99% задумаешься. :) |
25 сен 13, 15:30 [14883176] Ответить | Цитировать Сообщить модератору |
Elic Member Откуда: Сообщений: 30026 |
|
||
25 сен 13, 15:42 [14883286] Ответить | Цитировать Сообщить модератору |
happytoday Member Откуда: Днепр Сообщений: 239 |
Меня смущает эта картинка. Я бы посмотрел alert.log на предмет "Checkpoint not complete" |
||
25 сен 13, 16:07 [14883478] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Да, только БД не всегда дает возможность выбирать из больших количеств блоков. У нас, например, при нашей архитектуре Oracle блоки больше 16К не позволяет создавать. Допустимо: 4, 8, 16. Больше размер не сделаешь. Это касается и буферного кэша db_cache_16k и самого табличного пространства. На сколько понял, это от операционки и железа как-то зависит. Да у нас в 32К влезло бы все. И сцепленные блоки если полей больше чем 255, как понимаю, всегда образуются. Только вот с PCTFREE и размером блока соответствующего, Oracle мог бы их попытаться складывать в пределах одного блока. Ну что же... сейчас будем эксперименты строить с переносом на 16k tablespace... |
||
25 сен 13, 16:10 [14883491] Ответить | Цитировать Сообщить модератору |
dbms_photoshop Member Откуда: sqlmdx.net Сообщений: 5151 |
При нормальной раобте, если блок есть в кеше, Оракл на диск лезть не будет (undo не рассматриваем).
|
|||||
25 сен 13, 16:10 [14883495] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Эээээ... было-было что-то такое когда-то... *Не вот о таком ли речь идет?*
|
||||||
25 сен 13, 16:13 [14883515] Ответить | Цитировать Сообщить модератору |
Rb-Sr Member Откуда: Сообщений: 296 |
может сто́ит попробовать, если есть возможность? |
|||||
25 сен 13, 16:14 [14883521] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
happytoday, А что в картинке "не так"?... Там просто связь с базой по сети рвалась в этот момент (если про "площадку" речь"...) Что тут не так, профессор?.. |
25 сен 13, 16:15 [14883526] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
В начале месяца, когда были проблемы с UNDO вот такое вот появлялось пару раз, потом UNDO донастроили и все ОК стало.
|
||||||
25 сен 13, 16:20 [14883552] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
[quot Rb-Sr]
В том то и проблема, что эти поля "рабочие", на них в большинстве случаев весит индекс Oracle Text, но по ним идут и SELECT и UPDATE данных... Учитывая, что они не слишком уж заполнены и в бОльшей части они не большие, редко где они имеют по 30Кб данных... Как мне объяснили - возникнут тормоза при SELECT/UPDATE... Тем более, примерно 45% всех строк таблицы размером <=8k (т.е. в один блок помещаются). А если взять размер блока 16к, получаем что примерно 90% строк таблицы в блок 16к поместятся. OUT ROW LOB, весьма сильные тормоза дает на тестовой базе в нашем случае. |
|||
25 сен 13, 16:30 [14883605] Ответить | Цитировать Сообщить модератору |
Rb-Sr Member Откуда: Сообщений: 296 |
[quot sergey.semka]
П.С. Взяли бы да потестили разные варианты в сторонке. |
||
25 сен 13, 16:34 [14883620] Ответить | Цитировать Сообщить модератору |
happytoday Member Откуда: Днепр Сообщений: 239 |
Чем докажете, что связь по сети рвалась))). Пинги с сервером проподали? На узел зайти нельзя было? Если ответ ДА. Дальше можно не читать. И часто у Вас связь с базой по сети рвется? А может база просто очень занята была почти 15 минут и не хотела общаться. |
||
25 сен 13, 16:37 [14883644] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
База у заказчика стоит... мы ее просто сопровождаем. Соответственно Spootlight удаленно туда коннектится... Ну глюк со связью был, интернет пропадал тут... вот и связи не было. Слава богу база не "кидает" еще так... Хотя, глюки бывают... |
||||
25 сен 13, 16:50 [14883722] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
[quot Rb-Sr]
"Ожидания конкуренции за блок...." Звучит красиво... но почему они должны появиться?... Если у нас почти одна строка на один блок будет... И вероятность того, что одну и ту же строку будут править два разных пользователя (сессии) минимальна на самом деле. Система, конечно, не "одно пользовательская"... там в лучшие времена бывает 150 пользователей. Но обычно что-то около 50 пользователей постоянно. Только вот, проблема, конечно есть в самом процессе, не скрою... Сначала появляются строки новые.... (полупустые)... а затем их начинают "наполнять"... Ну для этого PCTFREE и увеличили... |
||
25 сен 13, 16:54 [14883740] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Ну чем доказать... вот этим пойдет доказательство?
|
|||
25 сен 13, 17:00 [14883785] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Конечно, там есть какая-то херь, под названием: Thread 1 cannot allocate new log, sequence 18604 Private strand flush not complete которая, напрягает... только так и не смогли понять что это... |
25 сен 13, 17:01 [14883791] Ответить | Цитировать Сообщить модератору |
happytoday Member Откуда: Днепр Сообщений: 239 |
Лично я от этой надписи в alert.log попытался бы избавиться. Например вот что пишут: http://habrahabr.ru/post/132107/ http://my-oracle.it-blogs.com.ua/post-181.aspx |
||||
25 сен 13, 17:10 [14883847] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Благодарю за наводки... попробуем избавиться. Просто до этого "избавиться" не получалось... (уже размер увеличивали... но что-то все равно никак). |
||||
25 сен 13, 17:21 [14883909] Ответить | Цитировать Сообщить модератору |
happytoday Member Откуда: Днепр Сообщений: 239 |
Я думаю все таки база была очень занята и не хотела общаться))) 14878147 |
||
25 сен 13, 17:25 [14883932] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
В общем проблема в этом есть.... Но вот "Checkpoint not complete" возникала, когда проблемы были с UNDO... это все решили. А сейчас 3 штуки DBWn... + 6 групп REDO весьма большого объема... Но все равно проблема "Thread 1 cannot allocate new log, sequence 18387 Private strand flush not complete" регулярно возникает при этом рандомно... Везде советуют "увеличить REDO", сделать больше групп... и все такое. У нас не так интенсивно работа идет. DBWn вообще простаивают большую часть времени... и их 3 штуки... ARCn вообще нет (не включены на этой базе архлоги, не спрашивайте почему). Но вот рандомно появляется вот эта проблема: "Thread 1 cannot allocate new log, sequence 18387 Private strand flush not complete" при этом "Checkpoint not complete" мы не видим! То есть Checkpoint нормально проходит. Вот куда копать - уже даже не знаем... на куче ресурсов написано что-то типа "забейте болт на эти строчки в Alert.log", типа это не страшно. Но "ожидания" то какие-то иногда возникают, если он не может "переключит лог", при этом вообще рандомно все.... то каждый час такая хрень, то двое суток без алертов... |
25 сен 13, 17:51 [14884067] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
А думать там нечего. Я же говорю, что она не была занята и на площадке клиента с ней работали... все прекрасно... Это у нас связь рвалась... А вот эти строчки из alert.log - см. предыдущее сообщение мое... |
||||
25 сен 13, 17:53 [14884075] Ответить | Цитировать Сообщить модератору |
Rb-Sr Member Откуда: Сообщений: 296 |
|
||
25 сен 13, 18:02 [14884141] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Вот, сделал: (в приложенном файлике "статистика" из сессии, которую Toad отображает собирая отовсюду...)
|
|||
25 сен 13, 21:41 [14884746] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
(в приложенном файлике "статистика" из сессии, которую Toad отображает собирая отовсюду...) К сообщению приложен файл (SESSION_STATISTIC.xls - 80Kb) cкачать ![]() |
25 сен 13, 21:43 [14884748] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||||
25 сен 13, 23:53 [14885193] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
|||||
26 сен 13, 00:06 [14885242] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Согласен с тем, что тут написали. Целиком и полностью. Просто сейчас получается что при "произвольных единичных чтениях" Oracle натыкается на мигрировавшие строки... И в виду нашей "говноситуации" избавиться от них мы просто так не сможем. Я писал уже, что "table move" делали месяц, два назад. Но в виду уникальности "говнопроцесса" мы получаем следующую логику: Ситуацию бы мог спасти PCTFREE, но так как итоговый "средний объем" записи около 10Кб у нас смысла это не даст... ибо мы не можем нормально использовать это, т.к. размер блока априори меньше нужного для хранения "средне-заполненной" записи. От этого и move table сильно не спасает.... Итог, - будем делать табличное пространство на 16Кб. И туда таблицу забрасывать с указанием PCTFREE = 70%. А с трассировкой на "конкретной глюк-записе" я попробую ближайшее время эксперименты провести. П.с. реальная выборка идет с использованием индексов, а не как в данном примере делали. По этому получается, что Oracle по rowid бегает несколько раз за всеми сцепленными блоками в нашей ситуации. Просто что именно Oracle делает, когда блоки эти "горячие" и в буферном кэш лежат... хотя и запись состоит из 2-7 сцепленных блоков... Когда он по индексу определяет rowid записи... Вероятно, он начинает "метаться" по кэш в поисках всех этих блоков от записи. |
||
26 сен 13, 11:27 [14886372] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||
26 сен 13, 12:57 [14886921] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||
26 сен 13, 13:04 [14886960] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Ну они априори есть: ANALYZE TABLE tablename LIST CHAINED ROWS; показал, что CHAINED_ROWS заполнилась: count(*) from CHAINED_ROWS where TABLE_NAME='MYTABLE'; Возвращает: 1.851.080 И выборка в режиме: SELECT /*+ FULL(p) */ * FROM MYUSER.MYTABLE p WHERE ROWID IN (SELECT HEAD_ROWID FROM MYUSER.CHAINED_ROWS) AND ROWNUM<=10000; Показывает весьма интересную выборку (продолженные чтения и т.д.). См приложенный файл. Просто тест с count(*) не дает этих продолженных чтений... тест с count(*) просто пробежал по первым блокам, посчитав их и не стал фетчить "сцепленные"... Вот в приложенном файле статистика из такой вот выборки на 10 тыс. произвольных строк из тех, что в CHAINED_ROWS попали... К сообщению приложен файл (SESSION_STATISTIC2.xls - 30Kb) cкачать ![]() |
||
26 сен 13, 15:20 [14888055] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
получилось при выборке в селекте 10 тыс строк, мы получили: table fetch continued row = 8 637 |
26 сен 13, 15:22 [14888072] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
город-герой, Владивосток, лег спать.... А остальным видать сказать уже и нечего... Ну хоть на этом спасибо ответившим... Хотя часть проблем так и осталось не решенных... |
26 сен 13, 17:51 [14889119] Ответить | Цитировать Сообщить модератору |
happytoday Member Откуда: Днепр Сообщений: 239 |
sergey.semka, Как вариант, могу предложить Вам посмотреть в сторону фрагментация MFT NTFS. Windows все таки. Но это вопрос уже не к Ораклу, а файловой системе |
26 сен 13, 18:09 [14889221] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Кстати, да... Там хоть и СХД какое-то, но все же... спасибо. Посмотрим. |
||
26 сен 13, 18:20 [14889258] Ответить | Цитировать Сообщить модератору |
Хф
Guest |
От migrated rows тебе не спастись - строка больше блока. Спастись от chained rows можно. Поскольку у тебя очень вырожденный случай - возможно это выход. Правда, не уверен что это работает на SE1 :) Нужно сделать хакан-фактор равным 1 1. Создаем таблицу 2. Вставляем одну строку 3. ALTER TABLE MINIMIZE RECORDS_PER_BLOCK 4. Заливаем остальные строки 5. Тестируем производительность |
27 сен 13, 00:32 [14890485] Ответить | Цитировать Сообщить модератору |
dbms_photoshop Member Откуда: sqlmdx.net Сообщений: 5151 |
Пора ставить 12с. Там "table access by index rowid batched" должно решить проблему. |
||
27 сен 13, 00:33 [14890489] Ответить | Цитировать Сообщить модератору |
хф
Guest |
некорректно термины использовал. с точностью до наоборот :) |
||
27 сен 13, 02:58 [14890655] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
Но я не прав с моим тестом с fullscan, т.к. если запрос не затрагивает колонку из другого блока, то и искать вторую часть колонок он не будет. Поэтому тест надо повторить поставив select count(последняя_колонка) from проблемная_таблица.
|
|||||||
27 сен 13, 07:47 [14890747] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
И все-таки повторюсь вот тесткейс который может быть у тебя Индекс вместо полного сканирования.. Если ты апдейтишь поле-поля начиная с 255 колонки, то у тебя будут образовываться chained rows несмотря на то что строка влазит в блок. И никакими pctfree и размерами блока ты это не вылечишь. Такая реализация у Oracle. Но move поможет с этими chained rows. |
27 сен 13, 09:33 [14890962] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
Собственно вот тесткейс когда на пустом месте мы получаем строчку в 245 блоках. Таблица tst содержит 500 колонок number. Просто такая реализация. SQL> truncate table tst; Table truncated. SQL> insert into tst(n1) values(1); 1 row created. SQL> SQL> commit; Commit complete. SQL> select blocks from user_segments where segment_name='TST'; BLOCKS ---------- 8 SQL> begin for i in 255..500 loop execute immediate 'update tst set n' ||i ||'=1'; end loop; commit; end; / 2 3 4 5 6 7 PL/SQL procedure successfully completed. SQL> SQL> commit; Commit complete. SQL> select blocks from user_segments where segment_name='TST'; BLOCKS ---------- 256 SQL> select count(*) from tst; COUNT(*) ---------- 1 SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row'; NAME VALUE ---------------------------------------------------------------- ---------- table fetch continued row 0 SQL> select count(n500) from tst; COUNT(N500) ----------- 1 SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row'; NAME VALUE ---------------------------------------------------------------- ---------- table fetch continued row 244 SQL> alter table tst move; Table altered. SQL> select blocks from user_segments where segment_name='TST'; BLOCKS ---------- 8 |
27 сен 13, 10:01 [14891098] Ответить | Цитировать Сообщить модератору |
Вячеслав Любомудров Member Откуда: Владивосток Сообщений: 18509 |
Оп-па Интересненько Я всегда считал, что будет только две "подстроки" 1-254 и 255-500, а получается, что любое новое поле (кроме уже существующих) в отдельной операции за пределами 254 создает отдельную "подстроку" ? Как-то не очень оптимальный подход. Почему бы не увеличивать второй кусок (255+), а не плодить новые "продолжения" |
27 сен 13, 10:21 [14891188] Ответить | Цитировать Сообщить модератору |
Вячеслав Любомудров Member Откуда: Владивосток Сообщений: 18509 |
А вот то, что оно продолжение в новый блок пихает, это, скорее всего, особенности ASSM ? |
27 сен 13, 10:22 [14891197] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
Да вот по-моему это не ASSM, а просто оно так устроено. |
27 сен 13, 10:26 [14891230] Ответить | Цитировать Сообщить модератору |
dbms_photoshop Member Откуда: sqlmdx.net Сообщений: 5151 |
SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row'; NAME VALUE ---------------------------------------------------------------- ---------- table fetch continued row 0 SQL> select min(ora_hash(id1)) dummy from t; DUMMY ---------- 391485597 SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'table fetch continued row'; NAME VALUE ---------------------------------------------------------------- ---------- table fetch continued row 0 |
||
27 сен 13, 11:32 [14891631] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
И так каждый месяц делать MOVE?.. А резмер блока в 16Кб и PCTFREE=99% не спасет тоже?... |
||
27 сен 13, 14:54 [14893221] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||||
27 сен 13, 14:56 [14893244] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Я знаю, что после 255 полей, Oracle сцеплять начинает. Но вот на каждое поле чтобы "сцеплял" - это конечно, крутая гипотеза... Просто я знаю, что Oracle даже если сцепляет - то "по возможности старается сохранить эти "сцепленные" блоки в одном блоке. Он же не идиот фрагментацию себе устраивать сам... Кстати, на твоих тестовых таблицах физические атрибуты хранения, такие как "Percent Free", "Percent Used", "PCT INCREASE", "FreeLists" сколько были?... может быть он в таком тесте (через цикл) не может получать значения... не видит, что блок свободный и выделяет новый?.. Кто-то в доку ткнуть может по поводу проблемы "сцепления после 255+ поля в таблице" и данный тестовый пример... |
||
27 сен 13, 15:02 [14893294] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Мув делали месяца полтора назад. Тогда помогло частично. А в связи с тем, что 255+ полей - всяко там Chained записи идут... |
||
27 сен 13, 15:03 [14893310] Ответить | Цитировать Сообщить модератору |
wurdu Member Откуда: Владивосток Сообщений: 4441 |
|
||||
27 сен 13, 15:07 [14893348] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
wurdu, Кстати, по поводу NULL-полей в конце. Мне один весьма уважаемый и компетентный специалист сказал, что в конце как-раз нужно переносить самые "толстые" поля из самых редкоиспользуемых... чтобы Oracle сцеплял их. И именно их скидывал в конец (в сцепленные). Тогда если к ним запроса не будет - они никогда "читаться" не должны... Хотя, если всегда запросы будут типа "SELECT *" - мне подсказывает задница, что Oracle все равно будет читать все поля... так что это монописуально становится... Учитывая, что есть клиенты от Forms 6i, которые работают тоже с этой табличкой - так Forms всегда делает выборку всех полей и всех их обратно UPDATE, на сколько я представлять.... Короче, "попкорн жарим" в микроволновке, получается в нашем случае... :( |
27 сен 13, 15:15 [14893441] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Вообще в подтверждение твоей теории:
Oracle® Database Concepts 11g Release 2 (11.2) Что собственно и логично... |
||||
27 сен 13, 15:24 [14893529] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
А вот тут сказано, что он не так работает...(см. предыдущее сообщение). Все же он кусками клеит по 255 |
||
27 сен 13, 15:27 [14893554] Ответить | Цитировать Сообщить модератору |
6124
Guest |
Одна поправка - Любое новое поле - которое дальше предыдущих непустых попробуй перед циклом SQL> begin for i in 255..500 loop execute immediate 'update tst set n' ||i ||'=1'; end loop; commit; end; сказать update tst set n500 = 1; Ораклу придется аллоцировать предыдущие 499 полей в блоке данных. Пока не знаю объяснения - но могу предположить что связано это с тем, что последние пустые колонки в строке не хранятся - стало быть даже если в таблице > 255 колонок - оракл не знает сколько конкретно будет row_pieces - может 1, может 2, а может и больше. Но разбивать сразу по 255 колонок - нецелесообразно - а вдруг их и не будет. С другой стороны,похоже что migrated rows обрабатывать легче чем chained rows (в том числе и migrated row pieces) - поэтому он до последнего (лениво) надеется что пусть будет много указателей на migrated row piece чем потом придется разбивать один row piece еще на промежуточные под-кусочки. p.s. все выше - в порядке пятничного бреда. (пока) |
||
27 сен 13, 15:35 [14893623] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Кстати, да! Вот видимо это Олег и пытался мне сказать, советуя чтобы я "максимально заполненные поля из минимально использованных в конец запихал в моем случае - чтобы сцепленных блоков меньше было. Тогда все становится понятнее. Тогда (в моем случае "попкорна" надо самые толстые и заполненные в конец пихать, чтобы Oracle сразу выделял под эти блоки место и эти "толстые" поля, которые по факту будут "во второй половине сцепки" (т.е. во вторых 255+ полях) как можно реже поднимались через "продолженные чтения". |
||||
27 сен 13, 16:23 [14894009] Ответить | Цитировать Сообщить модератору |
6124
Guest |
тогда уж alter table tst add (end_of_row integer default 1) (только нужно реально move сделать - а то оракл мухлевать научился с добавлением дефолтовых колонок |
||
27 сен 13, 16:28 [14894039] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
6124, Ну в нашем случае 2+ млн записей. 1) табличное пространство создаем новое на 16К; 2) Исходную таблицу переименовываем. 3) Создаем новую таблицу, меняя порядок полей на нужный нам... выставляя Initional Extend... PCTFREE = 99%; 4) Insert into таблица (поля в нужном порядке) Select (поля в нужном порядке) FROM переименованная таблица Order by PKEY; 5) Все индексы + триггеры + контекстные перестягиваем на новую таблицу (пересоздаем на ней). Просто в случае нашего "попкорна", когда вставляются новые записи с 10% заполенния... а потом туда "довливаются" записи... Нам нужно сократить миграцию в 0! иначе получать всегда будем, что по индексам будет бегать искать "перемещенные" строки, нарастать фрагментация и "перемещенные строки"... Как-то так. |
27 сен 13, 17:05 [14894281] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
6124, Ну если он постепенно "доращивает" указателями... создавая структуру на подобии "связанного списка" - тогда еще больше понятно стало откуда у нас такая "хрень". Дело в том, что поля у нас постепенно появляются... одно, потом другое... потом третье... (это что касается 255+ полей)... Соответственно, они могут появиться сразу +10 полей, а могут по одному... И заполнение тоже отдельными кусками... Типа может добавиться 10 пустых полей в конец, понятно дело... Затем заполниться 3-е с конца поле. Потом 7 с конца поле... потом остальные начинают "вдуваться"... И еще и в первом куске "наращиваются" объемы заполнения CLOB полей... В итоге там все "мигрирует" и "сцепляется" с неимоверной силой... и эти "несчастные" 2,2 млн записей при объеме 8гб информации начинают "вешаться". Видимо как-то так... |
27 сен 13, 17:11 [14894308] Ответить | Цитировать Сообщить модератору |
dbms_photoshop Member Откуда: sqlmdx.net Сообщений: 5151 |
Касательно null в конце, ноги растут оттуда, что в этом случае он занимает ноль байт, а не один. Это перпендикулярные подходы. |
||
27 сен 13, 18:15 [14894567] Ответить | Цитировать Сообщить модератору |
Sergei.Agalakov Member Откуда: Сообщений: 575 |
16k блок - это хорошо, но почему бы все-таки не нарезать таблицу вертикально на несколько таблиц, а Forms подсунуть view связывающую все узкие таблички с intead of триггером? Эдакий кластер наоборот. Как-то не верется, что у вас все запросы вида select * из таблицы с 400+ колонками. А так можно будет физически логично сгруппировать колонки обычно используемые вместе в одном запросе, да и pctfree индивидуально назначить - на таблицы со статичными колонками побольше, на часто обновляемые поменьше. Больший блок как-то поможет пока вы с вашим подходом еще 100500 колонок не добавите к этой таблице. Все-таки надо озаботиться редизайном, а обратную совместимость с приложением обеспечивать вьюшками. |
27 сен 13, 19:39 [14894815] Ответить | Цитировать Сообщить модератору |
sergey.semka Member Откуда: Санкт-Петербург Сообщений: 182 |
Редизайн не получится сделать хотя бы по тому, что есть специально обученные люди "настройщики", которые сами добавляют в неких метаданных поля, их типы, выбирают таблицы, связочные таблицы - все создают... и вся система "мультинастраиваемая"... От этого и проблемы... Соответственно с view тоже не прокатит - ибо в специальных настроечных табличках эти "настройщики" прописывают поля, которые нужны, прописывают то, где это все высвечиваться будет - в какой форме, на какой закладке и прочее... Какие вью - какие поля используют и т.д. и т.п. - и все это через Oracle Forms Application Programming Interface (API), Oracle Forms(6i/9i/10g) C/C++ API заносится в Forms, компилируется и один только черт знает откуда там все берется и куда какие поля попадают... Однако трассировки показывают, что Forms делает "select ДЛИННЫЙ СПИСОК ВСЕХ ПОЛЕЙ ЧЕРЕЗ ЗАПЯТУЮ from mytablename for update"... Но это уже другая история. А на счет "нарезки вертикально" - Oracle по сути это и делает в результате "chained rows" - основная его задача разрезать на куски по 255 полей... Просто если все данные "совместно" используются - тогда все будет на JOIN падать... там другие проблемы начнутся.... Ибо нет полей, которые вообще не правятся... они все время от времени могут меняться... за исключением небольшого набора квази-стабильных полей. Вот такая-вот бредятина... Выражаю большую благодарность всем, кто откликнулся и просветил... Особая благодарность и привет Владику... он же Владивосток: если нужно - могу сказать по какому адресу подъехать и получить свое "пиво" =) |
||
27 сен 13, 20:12 [14894889] Ответить | Цитировать Сообщить модератору |
Sergei.Agalakov Member Откуда: Сообщений: 575 |
Могу только посочувствовать. Если начальство вменяемое, то объясните ему, что все костыли и пластыри могут вам помочь только на ограниченное время. Пока 'это' еще работает необходимо начать работы по полному редизайну системы. Если начальство невменяемое, то с проекта надо сваливать, чтобы не оказаться похороненным под его обломками. |
30 сен 13, 21:23 [14903851] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: 1 2 3 4 5 [все] |
Все форумы / Oracle | ![]() |