Percona Server for MongoDB основана на MongoDB Community Edition, но сверху мы добавляем enterprise фичи. При этом они полностью бесплатны и все исходники открыты. Наш оператор тоже полностью бесплатный (и открытый), есть бэкапы, шардинг и прочие ентерпрайзные фишки. Очень рекомендуем.
Спасибо, кстати, надо бы попробовать на тестовом трупике дома :)
11.2.0.2.5 Oracle Linux 5 + uek. Заметили баг, когда аудит базы проводили. Ещё и WRI$_OPTSTAT_HISTHEAD_HISTORY не пурджится. А мануал пурдж бежит по 48 часов на неделю статистики :(
Причём, что самое интересное, сплиттинг через alter session set "_swrf_test_action" = 72; срабатывает. Даже пурдж срабатывает (я руками сделал сплит, через неделю ещё сплит, вот на днях ушла вторая партиция. Оригинальная огромная партиция так и осталась висеть). Саппорт разводит руками. Есть, вроде бы, патч, но он требует перевода базы в апгрейд, чего бы не хотелось, я не продавлю наверх. Наверное, в ежевоскресный мэйнтенанс добавится ещё один шаг. Эх, ладно, пожаловался на жизнь :)
В ASH снимаются снэпы со всех сессий каждую секунду (поэтому стоит иметь в виду, что даже в ASH некоторые сессии не успеют попасть), а в АВР уходит 10% сэмплов Эша каждые Н минут. У нас 60. ASH же чистится не по времени, а по наполненности, насколько я понял, потому что на тихих непродах, поросших мхом, можно и за вчера остатки данных найти :)
Причём, в данный момент я борюсь с багом (которому нет фикса, привет, Оракл), из-за которого WRH$_ACTIVE_SESSION_HISTORY не сплитается и не пурджится. С февраля 2012 она выросла лишь до 14ГБ примерно. Это та таблица, к которой обращаешься через dba_hist_active_sess_history. Соответственно, если бы можно было хранить эш 1:1, она была бы 140ГБ. Почти за год! На нагруженном продакшне под EBS+SOA+OBIEE+whatnot. Т.е. хранить неделю ASH 1:1, по-моему, не проблема.
Потому что у нас на проде ASH смывается примерно за час-полтора. Не всегда этого времени хватает, чтобы до конца решить проблему производительности. Иногда, если жалоба пришла чуть позже, из AWR просто невозможно уже вытащить нужные данные. Звучит, конечно, довольно наивно, но я не раз сталкивался с ситуациями, когда жалел об отсутствии выгрузки эша на диск 1:1, а не 1:10.
Спасибо за отличную статью. Как жрец ДБА, посмеялся от души. А Оракл… Уже скоро будет 12c, а долговременное хранение ASH data нет, только 10% в авр. Я готов сотни гигабайт под ASH снэпы отдавать, но хоть убейся.
lumia 800, с лета появилась проверка орфографии и рабочая замена во всех приложениях, раньше, действительно, бесило жутко.
Отдельной строкой — спасибо за пост, буду показывать друзьям, спрашивающим о минусах. Глюк с завершением вызова бывает. Ещё, бывает, если вызов пришёл из-под заблокированного экрана, то потом просто секунд 30 всё черно и не реагирует на нажатия.
252ГБ на ноду, две ноды. Вообще, не самое удачное архитектурное решение, особенно учитывая, что BI ломится на эти же ноды. Ну да кастомер хозяин, будем с этим жить.
В целом, можно и без них жить. SGA даже в 8гб не часто нужно. SGA в 20гб большая часть ораклового саппорта считает потолком. При SGA в 100+ГБ вылазят интересны косяки, вроде внезапно замёрзшей на полчаса базе.
HugePages is crucial for faster Oracle database performance on Linux if you have a large RAM and SGA. If your combined database SGAs is large (like more than 8GB, can even be important for smaller), you will need HugePages configured. Note that the size of the SGA matters.
Ого, как в машине времени на 7 лет назад на «Жёлтый» (который всё равно зелёный) перенёсся! Спасибо за статью, хоть свой последний джойстик я подарил 3 года назад, но всё-таки подумываю купить себе новый.
Percona Server for MongoDB основана на MongoDB Community Edition, но сверху мы добавляем enterprise фичи. При этом они полностью бесплатны и все исходники открыты. Наш оператор тоже полностью бесплатный (и открытый), есть бэкапы, шардинг и прочие ентерпрайзные фишки. Очень рекомендуем.
11.2.0.2.5 Oracle Linux 5 + uek. Заметили баг, когда аудит базы проводили. Ещё и WRI$_OPTSTAT_HISTHEAD_HISTORY не пурджится. А мануал пурдж бежит по 48 часов на неделю статистики :(
Причём, что самое интересное, сплиттинг через
alter session set "_swrf_test_action" = 72;срабатывает. Даже пурдж срабатывает (я руками сделал сплит, через неделю ещё сплит, вот на днях ушла вторая партиция. Оригинальная огромная партиция так и осталась висеть). Саппорт разводит руками. Есть, вроде бы, патч, но он требует перевода базы в апгрейд, чего бы не хотелось, я не продавлю наверх. Наверное, в ежевоскресный мэйнтенанс добавится ещё один шаг. Эх, ладно, пожаловался на жизнь :)Причём, в данный момент я борюсь с багом (которому нет фикса, привет, Оракл), из-за которого WRH$_ACTIVE_SESSION_HISTORY не сплитается и не пурджится. С февраля 2012 она выросла лишь до 14ГБ примерно. Это та таблица, к которой обращаешься через dba_hist_active_sess_history. Соответственно, если бы можно было хранить эш 1:1, она была бы 140ГБ. Почти за год! На нагруженном продакшне под EBS+SOA+OBIEE+whatnot. Т.е. хранить неделю ASH 1:1, по-моему, не проблема.
Отдельной строкой — спасибо за пост, буду показывать друзьям, спрашивающим о минусах. Глюк с завершением вызова бывает. Ещё, бывает, если вызов пришёл из-под заблокированного экрана, то потом просто секунд 30 всё черно и не реагирует на нажатия.
Ну почему на хабре комментарии нельзя комментировать, а ещё почему с утра хочется спать и страдает внимательность :) Но это вековечные проблемы.
HugePages is crucial for faster Oracle database performance on Linux if you have a large RAM and SGA. If your combined database SGAs is large (like more than 8GB, can even be important for smaller), you will need HugePages configured. Note that the size of the SGA matters.
Вот что пишет сам Oracle, например
P.S. Пора в Лондон!