Мне интересно будет послушаь про статистику и отсутствие хинтов.
Например, есть табличка с миллиардом записей и индексированное поле в ней, содержащее, например, пару тысяч уникальных значений с очень неравномерным распределением по количеству — по некоторым значениям всего пару строк, по другим десятки тысяч и т.д
Как оптимизатор поймет, когда использование индекса будет эффективно, а когда быстрее просмотреть таблицу целиком, если в where есть условие для этого поля?
>Пользуетесь DBMS_JOB? В 11g это теперь включено в DBMS_SCHEDULER — надо переделывать.
Это не так, ничего переделывать не нужно — все что сделано на dbms_job будет работать в 11g без проблем :)
В целом с Вами согласен. Хотя, мне кажется, что простота поддержка больше зависит от качества менеджмента проекта, изначально — в первую очередь правильно разработанной реляционной модели БД и грамотно причесанных бизнес-процессов, качества документирования и т.п., а способы реализации в БД или нет могут влиять больше на то, где у нас будут узкие места в плане производительности, т.е надо выбирать исходя, что мы создаем — биллинг мобильного оператора (склоняюсь к БД) или, например, facebook (тут как раз надо все выносить).
Как говорят — если автоматизировать бардак, то получится автоматизированный бардак и ничего более :)
Если Вы brave enough и готовы оказаться буратиной для oracle support и, если есть тестовая системка, на которой можно проиграть хорошую нагрузку, то можете попробовать поменять параметр
_ash_disk_filter_ratio с дефолтного 10 на 1-ку :)
Испугали Вы меня этим багом, полез смотреть — все ок, партиции сплитятся каждые четыре дня, каждая объемом порядка 2Гб, хранятся за последние 3 месяца.
У меня 11.2.0.3.2 HP-UX IA64 + еще с десяток one-offs.
Я говорил про содержимое выборки, а не про скорость работы же :)
А чего там с insert — я, вроде, кроме append и parallel больше ничего не использую обычно.
>У нас второй день тормозит exadata… причины хрен найдешь.
А чего там искать-то? Зайти в какой-нибудь ейный enterprise manager, вкладка performance->top activity и все как на ладони.
Сколько активных сессий, по каким классам ожиданий и разбивки глубже. Самые тяжелый запросы и т.п…
Ну, статья от конкурентов вряд ли может претендовать на полную объективность :)
С другой стороны меня только радует, что у oracle по еще есть серьезные конкуренты и хотелось бы, чтобы их было больше. Так как по мне качетсво самой oracle rdbms в плане надежности с тех пор, как я им занимаюсь (1998) изрядно падает.
БД уже напоминает анекдот про самолет с бассейном и прочим, который теперь еще и попытается взлететь :)
Я предпочитаю полный клиент — там много всякого полезного по жизни. Это четвертый из семи диск в дистрибутиве.
Скачивать его можно с сайта oracle.com, но правильнее качать последний патч (с 11-ой версии oracle пачти являются полными дистрибутивами) с support.oracle.com 11.2.0.3
Это четвертый из семи диск в дистрибутиве.
А далее внимательно изучить приложенный readme на предмет intallation prerequests и сам installation.
Можно еще последний Opatch и PSU накатить для верности :)
Я о том, что тем, кто с 1997 года, например, пользуется oracle installer не кажется, что в нем есть что-то ненормальное :)
Он универсальный под все платформы — в этом его главный плюс.
dba может и не должен много программировать, но разбираться в чужом коде, не говоря про владении в совершенстве написанием запросов обязан.
Иначе какой может быть performance tuning?
Спасибо, очень классно написано! Повеселили от души! :)
Но, очень странное суждение про применение ExaData для DWH/OLTP
Я как раз считал, что ExaData идеальна для DWH так как:
1. умеет все классно параллелить
2. пропихивает условия из where на уровень «дискового массива», что в результате рвет на грелки все остальные решения, где надо через оптику или т.п прокачать терабайты данных между сервером и массивом.
А для OLTP, все что содержит в себе RAC при условии не заточенности приложений — один сплошной гемор — меж-инстансные блокировки и т.п. Это ужас-ужас…
Можно использовать функиональный индекс, но лучше все же попытаться сделать так, чтобы значения в колонку oracle_user попадали уже в uppercase.
Хотя бы потому, что поведение команды drop index для обычного индекса и функционального имеет важные для production системы отличие. Сможете найти, какое? :)
Ну, вот, садитесь, 2 балла :)
В oracle любой DDL содержит неявный commit. Т.е. операция create table user_data также производит неявный commit двух предыдущих insert.
Я бы все же советовал Вам изучить хотя бы основы SQL, реляционных баз, ACID-теста, блокировок и т.п., прежде чем лезть в такие дебри, как FGAC.
Я, конечно, понимаю, что «не боги горшки обжигают», но тут уж слишком бросается в глаза непрофессионализм.
В статье, конечно, еще очень много чего сильно режет глаз.
Например, в коде с созданием таблиц и вставкой в них пристутствует неявный commit, что не результат не влияет, но как-то некрасиво.
За создание объектов схеме sys руки надо отрывать сразу — хуже подлянки для dba не придумаешь. Представляете, что будет, если oracle захочет в 12-ой версии сделать своей объект с именем number_table?
Условие в таком виде upper(oracle_user) = upper(USER) не позволит использовать индексы.
Конструкция WHERE ud_user_id = ' || userid || ' приведет к парсингу и разростанию shared_pool из-за отсутствия параметризации.
При наличии достаточно большого кол-ва записей в таблице user_data и достаточного кол-ва сессий сервер ляжет по оперативке из-за массивов в памяти.
Ну и самое главное, что я пока не могу понять, почему нельзя в первом варианте просто заменить
select ua_id into userid from scott.user_allowed where upper(oracle_user) = upper(USER);return 'ud_id in (SELECT ud_id FROM scott.user_data WHERE ud_user_id = ' || userid || ')';
на
return 'ud_user_id in ( select ua_id from scott.user_allowed where upper(oracle_user) = upper(USER)';
Ну, или просто использовать обычный view, которые места и русурсов не занимают и как-то проще в администрировании, чем FGAC.
>Использование хинта NOCACHE, в функции предикате, необходимо для устранения ошибки политики безопасности, после
>изменения данных в строках, так как кэшированный запрос будет становиться устаревшим после изменения данных таблицы.
Вообще-то хинт NOCACHE имеет совершенно другое действие и тут совершенно лишний :)
Вообще, в прнципе не существует хинтов, которые могут влиять на результат выборки, разве что только на порядок строк или при использовании rownum, хотя и на это нельзя ни в коем случае нельзя закладываться в разработке :)
Например, есть табличка с миллиардом записей и индексированное поле в ней, содержащее, например, пару тысяч уникальных значений с очень неравномерным распределением по количеству — по некоторым значениям всего пару строк, по другим десятки тысяч и т.д
Как оптимизатор поймет, когда использование индекса будет эффективно, а когда быстрее просмотреть таблицу целиком, если в where есть условие для этого поля?
Это не так, ничего переделывать не нужно — все что сделано на dbms_job будет работать в 11g без проблем :)
В целом с Вами согласен. Хотя, мне кажется, что простота поддержка больше зависит от качества менеджмента проекта, изначально — в первую очередь правильно разработанной реляционной модели БД и грамотно причесанных бизнес-процессов, качества документирования и т.п., а способы реализации в БД или нет могут влиять больше на то, где у нас будут узкие места в плане производительности, т.е надо выбирать исходя, что мы создаем — биллинг мобильного оператора (склоняюсь к БД) или, например, facebook (тут как раз надо все выносить).
Как говорят — если автоматизировать бардак, то получится автоматизированный бардак и ничего более :)
_ash_disk_filter_ratio с дефолтного 10 на 1-ку :)
Испугали Вы меня этим багом, полез смотреть — все ок, партиции сплитятся каждые четыре дня, каждая объемом порядка 2Гб, хранятся за последние 3 месяца.
У меня 11.2.0.3.2 HP-UX IA64 + еще с десяток one-offs.
Посмотрел ash на своем проде — хранится последние 70 минут :(
Ох, да, спасибо. Почитал это:
guyharrison.squarespace.com/blog/2010/1/1/the-11gr2-ignore_row_on_dupkey_index-hint.html
Узнал для себя много нового. Очень надеюсь, что данный хинт разработчиками не буджет использоваться вовсе…
А чего там с insert — я, вроде, кроме append и parallel больше ничего не использую обычно.
А чего там искать-то? Зайти в какой-нибудь ейный enterprise manager, вкладка performance->top activity и все как на ладони.
Сколько активных сессий, по каким классам ожиданий и разбивки глубже. Самые тяжелый запросы и т.п…
С другой стороны меня только радует, что у oracle по еще есть серьезные конкуренты и хотелось бы, чтобы их было больше. Так как по мне качетсво самой oracle rdbms в плане надежности с тех пор, как я им занимаюсь (1998) изрядно падает.
БД уже напоминает анекдот про самолет с бассейном и прочим, который теперь еще и попытается взлететь :)
Скачивать его можно с сайта oracle.com, но правильнее качать последний патч (с 11-ой версии oracle пачти являются полными дистрибутивами) с support.oracle.com 11.2.0.3
Это четвертый из семи диск в дистрибутиве.
А далее внимательно изучить приложенный readme на предмет intallation prerequests и сам installation.
Можно еще последний Opatch и PSU накатить для верности :)
Все познается в сравнении. Не факт, что на другом продукте было бы лучше…
Он универсальный под все платформы — в этом его главный плюс.
Иначе какой может быть performance tuning?
Но, очень странное суждение про применение ExaData для DWH/OLTP
Я как раз считал, что ExaData идеальна для DWH так как:
1. умеет все классно параллелить
2. пропихивает условия из where на уровень «дискового массива», что в результате рвет на грелки все остальные решения, где надо через оптику или т.п прокачать терабайты данных между сервером и массивом.
А для OLTP, все что содержит в себе RAC при условии не заточенности приложений — один сплошной гемор — меж-инстансные блокировки и т.п. Это ужас-ужас…
Да, есть свои ньюансы, но в них разбираешься быстро и проблем минимум вдальнейшем.
Хотя бы потому, что поведение команды drop index для обычного индекса и функционального имеет важные для production системы отличие. Сможете найти, какое? :)
В oracle любой DDL содержит неявный commit. Т.е. операция create table user_data также производит неявный commit двух предыдущих insert.
Я бы все же советовал Вам изучить хотя бы основы SQL, реляционных баз, ACID-теста, блокировок и т.п., прежде чем лезть в такие дебри, как FGAC.
Я, конечно, понимаю, что «не боги горшки обжигают», но тут уж слишком бросается в глаза непрофессионализм.
Например, в коде с созданием таблиц и вставкой в них пристутствует неявный commit, что не результат не влияет, но как-то некрасиво.
За создание объектов схеме sys руки надо отрывать сразу — хуже подлянки для dba не придумаешь. Представляете, что будет, если oracle захочет в 12-ой версии сделать своей объект с именем number_table?
Условие в таком виде upper(oracle_user) = upper(USER) не позволит использовать индексы.
Конструкция WHERE ud_user_id = ' || userid || ' приведет к парсингу и разростанию shared_pool из-за отсутствия параметризации.
При наличии достаточно большого кол-ва записей в таблице user_data и достаточного кол-ва сессий сервер ляжет по оперативке из-за массивов в памяти.
Ну и самое главное, что я пока не могу понять, почему нельзя в первом варианте просто заменить
select ua_id into userid from scott.user_allowed where upper(oracle_user) = upper(USER);return 'ud_id in (SELECT ud_id FROM scott.user_data WHERE ud_user_id = ' || userid || ')';
на
return 'ud_user_id in ( select ua_id from scott.user_allowed where upper(oracle_user) = upper(USER)';
Ну, или просто использовать обычный view, которые места и русурсов не занимают и как-то проще в администрировании, чем FGAC.
>изменения данных в строках, так как кэшированный запрос будет становиться устаревшим после изменения данных таблицы.
Вообще-то хинт NOCACHE имеет совершенно другое действие и тут совершенно лишний :)
Вообще, в прнципе не существует хинтов, которые могут влиять на результат выборки, разве что только на порядок строк или при использовании rownum, хотя и на это нельзя ни в коем случае нельзя закладываться в разработке :)