best practices
Время от времени мне пересылают запросы от заказчиков, которые жалуются на производительность Oracle на AIX. При этом, жалобы конечно не абстрактные, а вполне конкретные, например - не работает ввод-вывод как надо и все тут, мол чините. Так же чисто статистически, обнаружилось, что если выполнить набор некоторых магических пассов, которые в простонародье называются best practices, то большинство проблем рассасываются сами собой (прямо как у кашпировского) , а те что остаются - являются весьма достойными, чтобы ими заниматься.
Конкретные примеры - мы обнаружили, что в установка AXI по умолчанию queue_depth (длина очереди на диски) для Oracle слишком маленькая и почти всегда ее нужно увеличивать для OLTP приложений. Или, другой пример, заказчик не использует large pages и жалуется на производительность. Ну и чтобы как раз и навсегда записать ответ, публикую ссылки ниже:
И вдогонку, те кто только начинают свои проекты, часто интересуются как сделать сайзинг
(http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1887)
А может быть у Вас OEBS и интересно как же он живет на IBM ? тогда читайте - IBM Supported Platforms for Oracle Applications (all acquisitions) (http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS2815)
Так как заказчики массово переходят сейчас со старых Sun и HP на IBM, то есть еще проблема - пытаются принести все свои наработки по настройкам на новую платформу. При этом аргументация железная - "ведь раньше работало, а вы нам песни поете что новая платформа лучше старой, так и здесь должно работать также" -). Могу сказать - на практике гораздо быстрее и лучше пройтись по ссылкам выше и сделать как написано там. Это тем кому "ехать", с теми кому "шашечки" мы долго, вдумчиво, параметр за параметром на протяжении (иногда) месяцев все равно приходим к тому же самому.
Конкретные примеры - мы обнаружили, что в установка AXI по умолчанию queue_depth (длина очереди на диски) для Oracle слишком маленькая и почти всегда ее нужно увеличивать для OLTP приложений. Или, другой пример, заказчик не использует large pages и жалуется на производительность. Ну и чтобы как раз и навсегда записать ответ, публикую ссылки ниже:
- Самое первое что необходимо проверить, используете ли вы поддерживаемые технологии (Power VM, GPFS) и какие планы у IBM по их поддержке (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4711)
- Minimum Software Versions and Patches Required to Support Oracle Products on IBM Power Systems [MOS ID 282036.1]
- Как IBM представляет себе работу Oracle на AIX. IBM Oracle Technical Brief. Oracle Architecture and Tuning on AIX (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100883)
- Oracle Real Application Clusters on IBM AIX : Best Practices in Memory Tuning and Configuring for System Stability (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101513)
- AIX: Top Things to DO NOW to Stabilize 11gR2 GI/RAC Cluster [ID 1427855.1]
- Oracle DB и RAC 11gR2 on IBM AIX : Tips and Considerations (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101176)
- Diagnosing Oracle® Database Performance on AIX® Using IBM® NMON and Oracle Statspack Reports (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101720)
И вдогонку, те кто только начинают свои проекты, часто интересуются как сделать сайзинг
(http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1887)
А может быть у Вас OEBS и интересно как же он живет на IBM ? тогда читайте - IBM Supported Platforms for Oracle Applications (all acquisitions) (http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS2815)
Так как заказчики массово переходят сейчас со старых Sun и HP на IBM, то есть еще проблема - пытаются принести все свои наработки по настройкам на новую платформу. При этом аргументация железная - "ведь раньше работало, а вы нам песни поете что новая платформа лучше старой, так и здесь должно работать также" -). Могу сказать - на практике гораздо быстрее и лучше пройтись по ссылкам выше и сделать как написано там. Это тем кому "ехать", с теми кому "шашечки" мы долго, вдумчиво, параметр за параметром на протяжении (иногда) месяцев все равно приходим к тому же самому.
Ссылка на tips с лишней скобкой в конце.
ОтветитьУдалитьА сайзин IBM случайно делает не так: "Напишите нам о вас все что возможно, отошлите нам, мы вам вышлем сайзинг. Не забудьте в конверт положить 100 баксов"?
;-)
>Ссылка на tips с лишней скобкой в конце.
ОтветитьУдалитьСпасибо, исправил
>Не забудьте в конверт положить 100 баксов"?
1000 баксов, это же IBM -))
>> Не забудьте в конверт положить 100 баксов"?
ОтветитьУдалить> 1000 баксов, это же IBM -))
...и это - еще со скидкой...
ranger.
Со старой техники (если база оракл была) на технику Oracle переходят. С какого будуна на IBM переходить-то? Oracle on Oracle -- оно и дешевле, и одного вендора потом трясти чтобы баги исправили. IBM под оракл будет существовать ровно столько, сколько этого захочет сам оракл.
ОтветитьУдалитьДмитрий,
ОтветитьУдалитьспасибо за ссылки последние версии документов.
ПС.
все документы обязательны к прочтению для тех кто
использует Oracle на AIX
http://odenysenko.wordpress.com
>> Oracle on Oracle -- оно и дешевле
ОтветитьУдалитьага, на маркетинговых слайдах :)
в реальной жизни, обычно, совсем наоборот
>Oracle on Oracle -- оно и дешевле, и
ОтветитьУдалитьПочему вы думаете что дешевле ? Примеры в студию пожалуйста.
Вы полностью зависите от одного вендора и будете платить столько и по тем правилам по которым скажет он.
>одного вендора потом трясти чтобы баги исправили
Опять таки если вендор один, куда вы денетесь с подводной лодки и зачем что-то исправлять ?
Отличные мысли.
ОтветитьУдалитьВоспользовавшись советом Дмитрия свой следующий автомобиль а куплю так: кузов я куплю от одного производителя, двигатель я куплю от другого производителя, салон от третьего, а трансмиссию от четвертого. После этого я сам, своими руками соберу из этих запчастей конечный продукт и буду на нем ездить. И сделаю я потому, чтобы не зависеть от одного вендора! А еще потому, что Дима говорит что именно так будет дешевле :)
Мы тут вообще в своем уме? Наоборот, в этом случае мы попадаем в зависимость от одновременно нескольких вендоров. В страшную одновременную зависимость, так как геморрой с поддержкой такого авто будет несопоставимо выше. Некому предъявить претензии. После исправления бага в каждой отдельной запчасти ответствнность все равно на том, кто собрал автомобиль по запчастям. Одновременно, такой автомобиль будет дороже. Даже если взять стоимость только запчастей и забыть о стоимости самостоятельной сборки. Просто целым автомобиль покупать дешевле. Одновременно, человек построивший автомобиль по запчастям не приобретает никакого унакального опыта, который можно где-то еще потом продать. Автомеханик, в опытом прикручивания японских коробок передач к немецким двигателям никому не нужен. Всем нужен специалист определенным маркам машин.
В информационных технологиях тоже самое, что и в автомобильной промышленности. Просто индустриализация рынка IT только начинается и пример с прикручиванием storage от ИБМ к серверу от оракл еще не вызывает гомерического смеха как бы это было в мире автомобилей, но по цене "окарл на ИБМ" уже всегда однозначно дороже и рискованнее. Не в отдельных примерах, а всегда. В любом примере эта комбинация "ИБМ на оракл" дороже чем "оракл на оракл". Нельзя привести примера когда "ИБМ на оракл" дешевле если мы сравниваем сравнимые между собой вещи. Происходит это, как и в автомобильной промышленности, потому, что по запчастям всегда дороже. Когда будете покупать "ИБМ на оракл" всегда спрашивайте У ОРАКЛ сколько будет тоже самое стоить если брать "оракл на оракл" и всегда будет дешевле.
Опять таки если вендор один, куда вы денетесь с подводной лодки и зачем что-то исправлять ?
ОтветитьУдалитьДима, в твоем кармане лежит iPhone и ты читаешь это глядя в экран Apple MacBook Pro. Это все совершенно закрытые технологии от одного вендора, которые ты уже не поменяешь на гавно от hp, htc или windows.
> в твоем кармане лежит iPhone и ты читаешь это глядя в экран Apple MacBook Pro Это все совершенно закрытые технологии от одного вендора,
ОтветитьУдалитьОтличный пример.
Компания Apple решила что выпускать патч для решения проблем с нашим зиним/летним врменем для iOS 4 ей не нужно, потому что она (Apple) хочет чтобы все перешли на iOS 5 - я ничего сделать не смог.
Пример поведения одного вендора в действии.
Теперь о закрытости. Я могу сменить телефон за 15 минут на любую другую модель потому что храню копию всех контактов во внешнем сервисе, который могу синхронизировать с чем угодно. На ноутбуке у меня стоят только программы, существующие одновременно на Windows и Mac платформах. Это обязательное требование.
К сожалению prod систему так легко с платформы на платформу не перебросишь, в этом и "неудачность" примера.
Но я лично никогда не пойду на полную зависимость от одного вендора -)
>кузов я куплю от одного производителя, двигатель я куплю от другого производителя, салон от третьего, а трансмиссию от четвертого
ОтветитьУдалитьВы не поверите конечно, но я езжу на автомобиле в котором двигатель...сделала вовсе не компания которая произвела этот автомобиль -) Шины, диски, тормозные колодки это неполный набор того что я знаю, что вовсе не имеет никакого отношения к производителю моего автомобиля. В таком состоянии он сошел с конвейера.
Когда я попытался купить фирменный бокс с шильдиком бокс на крышу мне с удовольствием его продали, правда оказалось что его производит ... Thule -)
>Когда будете покупать "ИБМ на оракл" всегда спрашивайте У ОРАКЛ сколько будет тоже самое стоить если брать "оракл на оракл" и всегда будет дешевле.
Мне так понравился ваш комментарий что хочу написать отдельный пост на эту тему.
Короткий ответ на эту фразу - это не так. Но спрашивать конечно же это не мешает -)
>прикручиванием storage от ИБМ к серверу от оракл еще не вызывает гомерического смеха
Да, кстати, если вы не знаете, у SUN не было своих hi-end дисковых массивов, их производил Hitachi, и так как Oracle не продлил контракта, то у Oracle вообще нет high end storage как класс.
Те даже если из всех сил захотеть - нет такого понятие - high end storage от Oracle. Midrange - скольку угодно, но не high end. Вот и вынуждены прикручивать кто что умеет.
Хорошо, полгода назад купили Pillar чтобы как то заткнуть эту дырку.
Еще раз - тема очень достойная отдельного поста, спасибо !
Давай отдельный пост! Давно пора. А то на сайте трафика нет никакого. Народ весь разбежался.
ОтветитьУдалитьВсе, что ты пишешь правильно, но оно не имеет отношения к поднятой теме. Машины конечно же лелают из деталей, которые в большинстве своем пере-заказаны у других производителей. Все верно. Но тема не про это.
Вот мы пришли в автосалон Land Rover. В любом автосалоне всегда есть два отдела: 1. Отдел готовых автомобилей 2. Отдел запчастей. Мы спрашиваем сколько стоит Discovery 3. Говорят 3 миллиона рублей. Мы обращаемся в отдел запчастей и спрашиваем сколько стоит такой же Discovery 3 по запчастям: отдельно кузов, отдельно салон, отдельно двигатель и отдельно трансмиссия. Какую калькуляцию выставит нам отдел запчастей? Чисто с технической точки зрения мы покупаем ту же самую машину *без* работы по ее сбоке, поэтому по логике должно быть дешевле. Но хрен! По запчастям получается 9-12 миллионов рублей. В 3-4 раза дороже (cходи и проверь цены если не веришь) Почему такая несправедливость? Потому, что так хочется фирме Land Rover. Ей не интересно продавать нам запчасти. Ей интересно продавать готовые автомобили. И фирма Land Rover установила цены на запчасти именно так, чтобы было интресно покупать готовые автомобили, а не отдельно запчасти. Обыкновенный обыватель (если только это не авто-фанат Lаnd Rover) никогда не купит машину по запчастям. Это экономически не выгодно. И сделано это искусственно, так как чисто технически отельные запчасти дешевле собранной машины. Мы это знаем.
Теперь посмотрим как устроена современная компания Oracle. После появления Engineered Systems появилось два отдела (просто это не заметно снаружи): 1. Отдел готовых решений 2. Отдел запчастей. Фанаты сборки решений из запчастей могут купить лицензии в отделе запчастей и прикрутить их потом самостоятельно к железу ibm при помощи гаечного ключа и паяльной лампы. Те же самые лицензии Oracle в составе готовых решений имеют другую цену. Все точно также как и в автосалоне Land Rover.
Весь фокус состоит в том, что купив запчасти у IBM все равно потом приходится идти в Oracle и покупать другие запчасти у Oracle. И в IBM и в Oracle покупаются запчасти. Ключевое слово запчасти. Забудьте на секунду о технологиях. Подумайте о ценах. Как бы IBM не старалась уменьшить стоимость своих запчастей, ораклу это по барабану. И даже на руку. Oracle будет делать так, чтобы суммарная стоимость решения "сделай сам из запчастей" была дороже, наказывая идеологических фанатов IBM рублем. Ораклу надо продавать готовые решения и он будет диктовать цены на запчасти, так как его запчасти являются неотъемлемой частью решений Oracle-IBM.
Bottom line:
* Решения IBM-Oracle будут существовать только пока этого хочет сам Oracle. А Oracle этого хочет пока ему выгодно продавать запчасти с большой маржой. Эта ниша рынка не контролируется IBM.
* Как только иссякнет толпа идеологических приверженцев техники IBM с последующим лицензированием на ней Oracle, то Oracle прикроет лавочку. Как он это сделал c Mainframes несколько лет назад. Как он это сделал недавно c Itanium.
* Если у IBM не появится базы данных лучше чем Oracle, то в долгосрочной перспективе IBM придется уйти из этой ниши рынка.
>Компания Apple решила что выпускать патч для решения проблем с нашим зиним/летним врменем для iOS 4 ей не нужно, потому что она (Apple) хочет чтобы все перешли на iOS 5 - я ничего сделать не смог.
ОтветитьУдалитьА на iOS 5 давно пора перейти! Тебе новую OS выпустили (бесплатно!), а ты переходить-таки не хочешь. Это аполитичное поведение. Поэтому хрен тебе патч на iOS 4. Компания Apple все правильно сделала. Может ты еще и против перехода на Oracle 11g втихую агитируешь? Да мы тебя за такое...
Кстати, идиотское решение с зимним/летним временем навреняка скоро отменят.
>Говорят 3 миллиона рублей
ОтветитьУдалитьОхренели совсем. У них же двигатели вываливаются, это же все знают !
>самостоятельно к железу ibm при помощи гаечного ключа и паяльной лампы
-))))) да я чуть ключ не выронил когда это прочитал -))
Будет пост. Вижу отступать некуда.
>Решения IBM-Oracle будут существовать только пока этого хочет сам Oracle.
Нет, вступать в прямую конфронтацию с компаний которая больше тебя и диверсицирована лучше - самоубийство
>то Oracle прикроет лавочку. Как он это сделал c Mainframes
Они все еще поддерживаются
>Если у IBM не появится базы данных лучше чем Oracle
БД лучше чем Oracle ? Да ты вообще понимаешь где ты это написал ? Только подпишись и мы тебя и в твоем Лондоне достанем !
>против перехода на Oracle 11g втихую агитируешь
ОтветитьУдалитьДа ты что, только 11g R2 !
>идиотское решение с зимним/летним временем навреняка скоро отменят.
Это Apple пролоббировал ?
-))))) да я чуть ключ не выронил когда это прочитал -))
ОтветитьУдалитьГлавное не выронить ключ прямо на паяльную лампу! :))))))
Прочитал комменты. Смеялся.
ОтветитьУдалитьСтоило Oracle начать продавать железо - и уже все остальное железо стало "идеологически неправильным железом".
Как бы и Linux не стал идеологически неправильной платформой. А идеологически правильным был бы только Solaris.
"Я Solaris. SPARC Solaris. SPARC Solaris на Oracle SPARC T4-4."
:)
Только в этом блоге отгремели войны по поводу Exadata, а сейчас начнется холивар по поводу T4-4 и Oracle Appliance. И все это "против IBM".
Пишите, Дмитрий. Я схожу в магазин за попкорном. :)
Железо x86 в составе DB Machine является несомненно идеологически правильным железом. Разбери машину на запчасти и сразу стало неправильное железо. Тоже самое железо, но уже неправильное. Собери назад и опять правильное :)
ОтветитьУдалитьТочнее даже так: вынул проводок из свитча и вся DB Machine сталa неправильной . Воткнул проводок назад и все стало назад правильным (если только оракл не заметил).
Одно и тоже железо может быть идеологически правильным и неправильным и даже менять свой статус во времени :)
>> Если у IBM не появится базы
ОтветитьУдалить>> данных лучше чем Oracle
> БД лучше чем Oracle ? Да ты вообще
> понимаешь где ты это написал ?
> Только подпишись и мы тебя и в
> твоем Лондоне достанем !
просьба сообщить дату доставания в лондоне - подскочу посмотреть! местом предлагаю world's end в кэмдене - там прикольно, и от трубы недалеко.
ranger.
World's End -- классное место. С удовольствием приеду туда из своей деревни обсудить с Ranger последние модные тенденции управления буффер кэшем и нюансы работы c отрицательными значениями SCN. Ну а как домашнего сидра выпьем, то тут и многонитиевые процессоры разложим по полочкам :^)
ОтветитьУдалить...А кого доставать-то собираемся? И почему на этот раз в Лондоне? Мне как-то больше Hungerford по душе.
да ладно, что ты - по таким вопросам к волкову обращайся, он и только он - настоящий специалист, не просто не растерявший хватку с уходом из оракла - но приумноживший ее! а мы так, мы чо, мы просто суппорт.
ОтветитьУдалитьranger.
Дмитрий, добрый день.
ОтветитьУдалитьУ меня конкретный вопрос про large pages.
Вы пишете: Или, другой пример, заказчик не использует large pages и жалуется на производительность., т.е. подразумеваете, что large pages нужно всегда использовать для лучшей производительности?
Тогда как в документе по Вашей ссылке: IBM Oracle Technical Brief. Oracle Architecture and Tuning on AIX (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100883) на стр. 34-35 скорее не рекомендуют использовать large pages без лишней необходимости (если я правильно понимаю, large pages всегда используется совместно с SGA pinning?):
64 KB pages are preferred over 16 MB pages since 64 KB pages provide most of the benefit of 16 MB pages, without the special tuning requirements of 16 MB pages.
...
The primary motivation for considering the pinning of SGA memory is to prevent Oracle SGA from ever being paged out. In a properly tuned Oracle on AIX environment there should not be any paging activity to begin with, so SGA related pages should stay resident in physical memory even without explicitly pinning them. In improperly configured or tuned environments where the demand for computational pages exceeds the physical memory available to them, SGA pinning will not address the underlying issue and will merely cause other computational pages (e.g. Oracle server or user processes) to be paged out. This can potentially have as much or more impact on overall Oracle performance as the paging of infrequently used SGA pages.
If not done properly, Oracle SGA pinning and/or the use of large pages can potentially result in significant performance issues and/or system crashes. And, for many Oracle workloads, SGA pinning is unlikely to provide significant additional benefits. It should therefore only be considered where there is a known performance issue that could not be addressed through other options, such as VMM parameter tuning.
...
7. Application and system performance should be observed with and without SGA pinning (in a stress test environment if possible). If there are no observable and quantifiable performance improvements due to SGA pinning, SGA pinning should not be used.
Как все-таки более "best practice", исходя из Вашего опыта?
>Как все-таки более "best practice", исходя из Вашего опыта?
ОтветитьУдалитьSGA -> large pages, PGA -> 64K pages
Я бы посоветовал поглядеть также на свеженький документ от 29 марта:
ОтветитьУдалитьAIX: Top Things to DO NOW to Stabilize 11gR2 GI/RAC Cluster [ID 1427855.1]
И, действительно, сделать это сейчас.
А что, для SAN (DS*) queue_depth тоже реально помогает ? (есть примерные цифры)?
ОтветитьУдалить> Да ты что, только 11g R2 !
ОтветитьУдалитьНа данный момент, самая лучша база Oracle - это 10g!
После того, как Oracle отдал development в Индустан... баг на баге...
Кстати, чтобы быть до конца честным, баг Oracle 11g R2 для Redhat Linux (32, 64-bit) не был воспроизведен на AIX 6.1. :o)
Вдогонку (из личного производственного опыта), даже IBM предпочел для одного из своих заказчиков именно Oracle 10g (точнее 10.2.0.4), а не "новомодный" 11g R2.
Удалить