please standby

По счастию до 16 августа здесь постов не будет. А я постраюсь увидеть и сфотографировать эту красоту. А там глядишь и 11g выпустят :)

Читать дальше...

Using Oracle Clusterware to Protect Single Instance Database 11g

Пошаговая инструкция как построить HA кластер при помощи Oracle Clusterware.
Как я уже писал, такая конструкция не требует дополнительного лицензирования.

SI_DB_Failover_11g.pdf (application/pdf Object)

Я почти уверен, что эта инструкция будет очень востребована.

Кстати, тоже самое уже можно сделать 10g. Я почти уверен :)

Читать дальше...

11g: Product Editions & Features

А мне очень понравилась ссылка :

Oracle Database 11g: Product Editions & Features

Просто, но со вкусом, с массой дополнительных ссылок на описание features.
Единственное, что там не хватает - ссылки на pricing

Читать дальше...

Oracle RAC SIG

Я обнаружил, что по недоразумению еще не написал о
Oracle RAC SIG web site

На мой взгляд, один из самых лучших технических открытых сайтов посвещенных Oracle RAC.

Читать дальше...

Direct NFS client (11g NF)

Наконец, появилась первая более техническая статья про NFS клиента в ядре 11g

directnfsclient_11gr1_twp.pdf (application/pdf Object)

Если я правильно понял, то теперь будут сняты ограничения на использование только сертифицированных устройств для хранение БД под NFS. Хотя явно, это и не сказано..



PS
Обратите внимание на файл $ORACLE_HOME/dbs/oranfstab :)

Читать дальше...

10.2.0.4 Patch Set

Уже можно "подсмотреть", что собираются исправить в 10.2.0.4
Metalink Note:401436.1

Однако по прежнему неизвестно, когда выпустят патч:
"
Please note that 10.2.0.4 has not been released on any platform , and does not have release dates available
"

Как только появиться определенность с датами - сообщу :)


Кстати, обратите внимание на
Bug 5667023 - Linux: CRS does not start after applying 10.2.0.3

там же есть workaround, действительно на RHEL 4 U4 нет таких проблем.

(меня уже кто-то спрашивал стоит ли переходить на 10.2.0.3 и приводил информацию, что
после обновления не стартует crs)

Читать дальше...

Linux GFS certify for RAC

Пока только обещана сертификация
GFS и 10gR2 RAC на RHEL5 ( вернее на Oracle Enterprise Linux 5, конечно же :)

С другой стороны Note:329530.1 содержит таки казуистические выражение насчет существующей поддержки GFS в RHEL 4 и 3.
Не могу это цитировать, это надо читать :)

И вообще, ASM наш выбор !

Читать дальше...

СУБД Oracle Database 10g – новые возможности для разработчиков

Судя по анкетам, одной из самых популярных презентаций на нашем семинаре
Oracle RAC: Deep Dive for Developers является презентация "СУБД Oracle Database 10g – новые возможности для разработчиков" которую Игорь Мельников (Igor.Melnikov) делает в рамках нашего семинара. Она неизменно вызывает большой интерес у слушателей.

Почему же в канун выхода 11g я выкладываю презентацию для 10g ?
Если коротко, то сейчас многие озабочены переходом на 10g, чтобы затем перейти на 11g. Подробнее о причинах можно читать ранее.

Читать дальше...

New Critical Patch Updates

Critical Patch Updates and Security Alerts

Читать дальше...

T2000 and Oracle RAC

"Generally speaking Oracle will scale well on Sun Fire CoolThreads servers" пишет нам Sun Microsystems и дает несколько советов по настройке.

Могу только согласиться. У меня была возможность сразу после появления T2000 ее протестировать. Ее 8 ядер немного проиграли 8 ядрам Ultra Sparc IV+ да и то, в пиковой нагрузке. При весьма ощутимой разнице в цене.

Единственное, что рекомендую проверить - это как сейчас дело обстоит с внутренней дисковой подсистемой. В момент выхода T2000 поставлялась с ужасающей дисковой подсистемой, размещать на ней БД я бы не рекомендовал. Также были проблемы с SAN карточками под эту модель. Сейчас я верю, ситуация изменилась.

Собственно совершенно не вижу причин почему бы не собрать RAC на 4-х таких машинках - по лицензионной политике проходит Standard Edition ( 4 socket), а значит RAC бесплатен. 32 ядра - это знаете ли сила. При цене железа ~ $45,000 (по Sun US price list). Вот здесь можно найти примерные цены на серверы SUN с UltraSparc IV+ и почувствовать разницу. При всем моем глубочайшем уважении к UltraSparc. Ничего нового я здесь не открываю, как всегда существует парадигма price/perfomance - каждый ее решает для себя

UPDATE 1.

Оказалось, что коллеги во внутренем mail-list'e недовольным T2000 на основании тестов у реальных заказчиков. Не буду приводить примеры тестирований, поскольку очень уж результат зависит от теста.

Приведу лишь короткое и очень мне понравившиеся сравнение технологий SF 890 и T2000

> A current V890 uses UltraSPARC-IV/IV+ dual core processors.
> The processor has a clock speed in the range of 1.2 GHz (low-end
> UltraSPARC-IV) to 1.8 GHz (high-end UltraSPARC-IV+). Each
> processor has 2 MByte L2 and 32 MByte L3 cache.
>
> A T2000 uses an UltraSPARC T1 processor with up to 8 cores.
> The processor has a clock speed in the range of 1.0 GHz to 1.2
> GHz. The processor has 3 MByte L2 cache but no L3 cache. The
> core is derived from the earlier UltraSPARC-II microarchitecture,
> so as a rule of thumb the core performs less work than a later
> generation core with the same clock speed, and potentially
> much less work than a later generation core with a faster clock
> speed and large L3 cache.
>
> This doesn't mean a T2000 can't be used successfully as a
> database server but it does mean that a T2000 can't be expected
> to match a V890 for a single threaded task.
>
> Maybe the following questions might help:
>
> 1) is the single threaded task on the critical path for the
> application, and if not, who cares?
> 2) a V890 is a single box which presents a SPoF, so what about
> HA requirements?
> 3) a V890 is potentially far more expensive in terms of both
> hardware and Oracle software than a pair of T2000's with
> equivalent throughput, so what about price/performance?
>
> I can't give you a magic solution if 1) goes against you but
> if straight line speed isn't the only factor then 2) and 3)
> might help. You will probably find that the software cost is
> the dominant factor in 3), especially when considering T2000
> servers.
>
> BTW the statement about FPU is not entirely correct and is
> unlikely to be relevant for most Oracle database workloads in
> any case:
>
> http://en.wikipedia.org/wiki/UltraSPARC_T1

Читать дальше...

RAC ЧАВО

Ниже я постараюсь ответить на несколько вопросов по технологии Oracle RAC, которые задаются на мой взгляд наиболее часто - RAC ЧАВО (Часто задаваемые Вопросы и Ответы). Хочу также поблагодарить Игоря Мельникова (Igor.Melnikov) за участие в сборе материалов. Данный пост обновлен 18.07 2007

Прежде всего мне хочется упомянуть малоизвестный факт об истории технологии RAC. Эта технологий появилась еще в версии Oracle 6, в 1985 году, до появления в СУБД Oracle pl/sql и знаменитого row locking механизма http://www.oracle.com/corporate/home2.html). Работала она правда только под VAX машинами. Уже в следующей версии, 7-ой Oracle Parallel Server работал на нескольких платформах.

Мне кажется, в IT очень важно понимать, сколько лет развивается та или иная технология. Потому что, часто они быстро появляются, и также быстро пропадают. В последние несколько лет тема Grid является заглавной для новых выпусков БД Oracle. Так 9i была выпущена со слоганом Unbreakable, подразумевая что ее "неубиваемость" основвывается на технологии Oracle RAC, версии 10g и 11g просто несут в себе индекс [G]rid. Итак, мы говорим о технологии, которой более 20 (!) лет.

Итак, вопросы которые часто задают:

1. Назовите где эта технология используется в России ?

Очень хороший вопрос. Примерно такой же хороший, как спросить "а имеют ли Ваши электроны Российское гражданство ?".
RAC - прежде всего технология, не зависящая от установленного в стране законодательства. Когда спрашивают про примеры использования бухгалтерской программы, то хотят уточнить, поддерживает ли она Росссийское законодательство. Это понятно, без этого использовать бухгалтерскую программу невозможно.
Но RAC - это технология. И законы физики работают, извините, вне границ государств.

Более правильный вопрос - "приведите пожалуйста примеры индустрий, которые используют данную технологию ?". OK, пожалуйста, познакомьтесь со специальным N страничным документом RAC customers book. Мне кажется там можно найти примеры по всем индустриям.

И все-таки почему так мало именно российских примеров внедрения RAС ?

a) Одна их причин в том, что ORACLE CIS работает только через партнеров. Т.е. все проекты проходят только через парнеров. Вот почему они не собирают/не публикуют references (а они есть, и очень большие ) - не могу сказать.

б) Наверно работает и наш Россиский менталитет - лучше ничего не говорить соседу, чтобы он не дай бог не позавидовал (?). Недаром есть даже анекдоты на эту тему. У нас вообще крайне неохотно говорят об используемых технологиях. Думаю, что увы, это наша Российская специфика. Вот Ваша организация готова выступить как reference использования технологий ?


2. Но ведь приложения в RAC не масштабируются и на одной большой машине работают лучше ? ( http://blogs.sun.com/dcb/entry/oracle_rac_s_secret)

Ответ очень прост: - если приложение не масштабируется, оно будет работать плохо даже на очень большой "железке". С примерами, я думаю, встречались очень многие.

Однако, действительно, до некоторой степени, RAC обнажает "узкие" места приложения. Думаю, что именно это и вызывает массовые слухи, о приложениях, которые не работают под RAC.

Я думаю, что лучшим ответом о масштабировании является, тот факт, что в RAC конфигурации работают SAP R/3 и Oracle E-Business Suite (последний в том числе в Россси :) ) Если приложение написано хорошо (а невозможно написать такого монстра плохо) - оно работает в RAC.

Из моего опыта следует, что приложения не всегда написаны хорошо. При переносе в RAC это становится видно. Но в этом случае, как правило, удается партиционировать приложение (т.е. разделить части приложения по узлам), что оставляет производительность как минимум на том же уровне, давай запас по процессорной мощности. Появляется время, для спокойного исправления ошибок.

Также в России (!) уже есть примеры, когда приложения "сжирало" самые большие имеющиеся на данный момент компьютеры (HP Superdom, SUN Fire 25K). Реальность таких IT - это непрерывно выспрашивать у вендора, когда будет более мощная машина. Я знаю примеры, когда откладывали внедрения новой бизнес функциональности из-за ожидания поставки очередного монстра.


3. Но ведь RAC это очень дорого ?

OK, давайте посчитаем. Прайс-лист Oracle доступен по адресу http://www.oracle.com/corporate/pricing/pricelists.html


Я выделяю 3 сегмента серверного оборудования:

- серверы начального уровня (2-4 процессора)
- серверы уровня предприятия (8 процессоров)
- high-end серверы (12 и более процессоров)


Серверы начального уровня

В большей своей массе в этом сегменте лидируют серверы с Intel архитектурой

Возьмем открытый прайс-лист компании Kraftway (www.kraftway.ru) от 09.07.2007

Увидим, что

Express 400 EM11 (4CPU Xeon 3Gz, 4Gb RAM) стоит 425,331 р

Express ISP ES24 (2CPU Xeon 3,2Gz, 2Gb RAM) стоит 94, 547 р

Для построения кластера нам понадобится 2 сервера Express ISP ES24 с общей стоимостью 189, 094 р

По лицензионным ограничениям на 2 2-х процессорных сервера можно установить Standard Edition, куда опция RAC уже включена бесплатно.

Итак, мы имеет разницу в цене между одним Express 400 EM11 и кластерным вариантом

425,331 - 189, 094 = 236,237 р ~ $9,000

( процессорные лицензии oracle стоят одинаково для обоих вариантов: 4 Socket * $15,000 )



Сервера уровня предприятия и high-end сервера


Я попробую посчитать на примере железа Sun Microsystems.
Нет, это не месть за пост Sun'овского инженера :) из предыдущего ответа. Я выбрал SUN, в первую очередь потому, что имеют многолетний опыт работы с техникой SUN, очень ее уважаю. Считаю, что Solaris - вообще одна из лучших ОС для Oracle (прошу это не обсуждать - это аксиома :)). Тот факт, что SUN испытывает (ывал) затруднения никак не связан с высочайшим уровнем ее технических разработок. Насколько я знаю, только в Sun Fire можно одновременно использовать процессоры нескольких поколений (!). Даже IBM не смогли (или не посчитали нужным) это реализовать.


Итак, я буду использовать открытый прайс-листы SUN по адресу
http://ru.sun.com/products/configurations/index.html


Давайте также учтем, что несмотря на размеры основного сервера, во всех серьезных организация принято устанавливать Standby DB или HA Cluster. С целью упрощения расчета стоимости я рассматриваю вариант Standby DB (см. также комментарии к посту ниже). Для варианта 1 сервера она нам нужна для отказоустойчивости и средства восстановления от логических ошибок, для варианта кластера - отказоустойчивость у нас уже есть, нужно только средство восстановления от логических ошибок.

Также в варианте 1 сервера бессмысленно ставить Standby DB на машину не равную основной - в противном случае она не сможет нести всю нагрузку промышленной системы.

Итак, Я взял несколько машин, все с процессорами UltraSPARC IV+, в каждой машине на процессор приходится 4Gb памяти.


Sun Fire V490 Server (4 CPU) - $65,000
Sun Fire V890 Server (8 CPU) - $131,000
Sun Fire E4900 (12 CPU) - $701,000
Sun Fire E6900 Server (24 CPU) - $1,409,000

Более полные спецификации с ценами


Серверы уровня предприятия
-------------
В качестве сервера уровня предприятия будем используется SF 890, в качестве равного ему кластерного варианта 2 сервера 2 SF490

Рассчитаем стоимость для SF 890

$131,000 (железо) + 8*$40,000 (процессорные лицензии Oracle) = $451,000

Рассчитаем стоимость для 2-х SF 490:

2*$65,000 (железо) + 8*$40,000 (процессорные лицензии Oracle) + 8*$20,000 (RAC option) = $610,000

$451,000 < $610,000 Как мы видим вариант RAC проигрывает на ~$160,000. Но давайте вспомним про Standby. Получим для SF 890 удвоение суммы, поскольку у нас две машины и Standby DB нужно полностью лицензировать. В кластерном варианте в качестве Standby достаточно поставить еще один SF 490 $902,000 ~ $610,000 + $65,0000 (железо) + 8*$40,000 (лицензия на standby) $902,000 < $995,000 Итак, мы видим, что RAC вариант проиграл грубо говоря ~$100,000 при общей стоимости системы ~$1,000,000. Теперь продумаем, что делать, когда нам потребуются еще скажем 2 CPU ? В случае SF 890 нам придется купить новое "железо", потратив $700,000 а в случае кластера - всего лишь докупить SF 490 - 65,000 (железо) + 4*$40,000 (Oracle) + 4*$20,000 (RAC options) = $305,000

High-end серверы
--------------------

В качестве high-end сервера будем использовать E4900 (12 CPU) , в качестве равного ему кластерного варианта 3 сервера SF490

Рассчитаем стоимость для E4900 (12 CPU)

$700,000 (железо) + 12*$40,000 (лицензии Oracle EE ) = $1,180,000

Рассчитаем стоимость для 3-х SF490:

3 * ( $65,000 (железо) + 4*$40,000 (Oracle) + 4*$20,000 (RAC options) ) = $915, 000

$1,180,000 > $915, 000

С RAC мы выиграли почти $280,000 !

Рассмотрим добавление standby. Для E4900 это удвоит стоимость системы, для кластерного варианта добавит еще один SF 490.

$2,360,000 ~ $915, 000 + $65,000 (железо) + 4*40,000 (Oracle)

$2,360,000 > $1,140,00

теперь разрыв увеличился до $1,120,000 (!)


При больших серверах разрыв еще больше увеличивается.



Выводы:

Удивительно, но в некоторых весьма реальных случаях экономия в случае использования RAC может составить порядка 1млн $. Вот так :).
Разрыв совершенно очевиден начиная с примерно 12 процессоров. На уровне 8 процессоров, следует учеть развитие ИС, standby систему - и выгода также будет очевидна. На уровне 4-х процессоров в игру вступает Standard Edition, куда опция RAC включена бесплатно.


Понятно, что я взял цены price лист без учета скидок, локальных налогов, технической поддержки. Что у разных вендоров картина может быть разной. Но я прошу Вас об одном - посчитайте. Это не очень сложно, а выводы могут быть весьма удивительными.


4. Если Все так здорово, то почему все-таки используют эту технологию не очень многие ?

Есть как минимум несколько причин:

a) "Железные" вендоры проводят вполне успешную политику. Очень часто, когда приглашают Oracle железо уже куплено и говорить о выборе технологии поздно. Можно лишь посоветовать начинать модернизацию IT с выбора технологии, а не большой железки.

б) Бюджетные организации страдают от необходимости продемонстрировать, куда именно вложили деньги. Если потратили $1 милллион на большой красивый шкаф - это понятно. А если на несколько маленьких машинок - то не очень. Я думаю, что все кто работал с бюджетными организациями понимает, о чем я пишу.

в) Мало кто хочет посчитать убытки от простоев. Страна большая. Подумаешь, уйдут одни клиенты, придут другие. В Европе совсем не так. Там автоматизированная бесперибойная система - основа бизнеса. За нее очень держатся. Она помогает зарабатывать деньги, а значит надо в нее вкладывыть.

PS
Если Вы все же остались недовольны моей идей использовать при подсчете standby - в следующем посте смотрите информацию про Sun T2000 :)

Читать дальше...

RAC and Database Vault

Будьте внимательны, совместное существование RAC и Database Vault имеет свои особенности.
Так после установки DBV ...перестанет стартовать автоматически БД. Чтобы это исправить, рекомендуется зарегистрировать БД с помощью crs_register влючая параметр
"USR_ORA_CONNECT_STR=sys/password as sysdba". Ну и надо быть осторожным настраивая правила. Коллеги, похоже перестарались, у них перестал работать даже backup...

Читать дальше...

Oracle and TimesTen

Поскольку головной сайт компании по прежнему считает новостью выход TimesTen 6 - спешу сообщить Вам, что с мая 2007 на всех основных платформах доступна Timesten 7.0.2

Основные возможности версии 7.0 можно прочитать в Features Overview

Я же расскажу о том, что мне понравилось на семинаре.

Начался он достаточно смешно. Сразу, до начала презентации спросили, зачем вообще нужен TimesTen если теперь в 11g есть client result set ?

Ответ был вполне убедителен. Result Set дает не более 25% выигрыша производительности. Действительно, ведь закешировать можно либо специально написанные выражение, либо вызовы с конкрентными bind переменными. Т.е. далеко не все. А TimesTan хранит все свои данные прямо в памяти и только в памяти. Что дает, в реальных ситуациях от 2-х до 4-х разов ускорения. Задумайтесь, никакая новая дисковая подсистема столько Вам не выдаст !

Надо ответить, что TimesTen весьма современная и полнофункциональная БД: собственный "sqlplus", собственный оптимизатор. Все вполне серьезно. А уж система Data Aging вообще вызывает восхищение.

Есть система репликации между отдельными экземплярами Timesten. Что позволяет строить отказоустойчивые системы.


После покупки Oracle быстрыми шагами вводятся возможности для упрощения использования TimesTen теми разработчиками, что работал с Oracle - функции decode, rownum и пр. Можно получить доступ к timestan из sql developer уже текущего релиза.

И наконец, самое основное: Oracle Сache connect - есть возможность прозрачно кешировать отдельные таблицы Oracle !
При этом можно настроить обновление измененных в Oracle данных в TimesTen !
Со стороны TimesTen CacheConnect представляет собой клиента Oracle поэтому поддерживаются
все фичи клиента такие как taf, ons


И кто же эти счатливые потребители TimesTen. Вы конечно можете не поверит, но почти половина успешных внедрений Timesten приходится на клиентов с Oracle RAC. Действительно, если Ваз так беспокоит одновременно отказоустойчивость и быстрота обработки - связка TimesTen + RAC не имеет себе равных.

Конечно есть и минусы:

- только одно соединение CacheConect с Oracle. Это может стать узким местом. Обещали исправить.

- прозрачный переход с использованием CacheConnect получается для java приложений.
конечно если у Вас Oracle Forms то придется мигрировать на java. OCI клиент пока не может ходить в TimesTen. Или я чего не понял, или это исправят (??)

Читать дальше...

certify and planning release info

- Ожидается, что 10.2.0.3 в июле 2007 будет доступен на всех платформах.
- Планов на 10.2.0.4 пока не объявлено. Можно предположить что его выпуск будет увязан в выпуском 11g
- 11g 32bit (?) Linux ожидается в августе 2007.
- Только что был сертифицирован 10gR2 под Oracle Enterprise Linux 5.

Читать дальше...

11g roadshow, part 4

Последняя часть моего рассказа об 11g roadshow.

Она посвещена наиболее "раскрученной" новинке в 11g - real application testing.

Рекомендую посмотреть презентацию этой технологии.

Ну и ниже мои комментарии:

Во-первых почему "real" - потому что проигрываться на тестовой систем будут ваши реальные транзакции с боевой системы. Т.е. Вам не нужно придумывать нагрузку, а нужно ее "захватить".

Делается это очень просто - на производственной системе включается ..трассировка на все сессии. Product manager пояснил, что все очень оптимально, на диск пишутся не сырые trace file, а уже в binary формате.

В принципе уже в 9i существовала возможность писать трассировки в кольцевой буфер в памяти и сбрасывать его на диск время от времени. Мне кажется данный механизм и используется. Только не было доступно извне, когда буфер заполнился, поэтому простым смертным это было тяжело использовать.


Знание как захватывается нагрузка дает нам:

- Прямо перед включением захвата нужен полный backup. Чтобы затем его восстановить на тестовой систем. Это повысит аккуратность "проигрывания". В противном случае часть транзакций, скажем, не найдет "своих" счетов.

- Нужно заготовить серьезное дисковое пространтсво под хранение данных

- Нужно приготовиться к уменьшению производительности.
Конечно, будет какое-то проседание производительности для конечного пользователя. В свое время мы исследовали как проседает производительность при включении обычной трассировки. Если это обычное OLTP приложение то можно оценить примерно в 10%


- Будут затрачены доп. ресурсы на захват

Ребята из внутренней группы тестирования провели тесты, с целью узнать накладные расходы. Так вот, для OLTP это примерно 10% доп CPU времени, для приложения, которое осуществлят массовую загрузку данных - в среднем 20%, но может доходить и до 40%


Проигрывание может осуществляться как в реальном режиме времени (т.е. с теми задержками которые были у Вас, так и в стресс-режиме - он позволят проиграть всю захваченную нагрузку быстрее)

Кочено гарантируется, что транзакции будут проигрываться в правильном порядке.

Можно ли осуществлять захват отдельных пользовательских сессий ? По документации можно, но по bug report'ам похоже, что пока это не работает.

Из общих соображений понятно, что поскольку все захвачено в binary виде, то нет возможности вмешаться в SQL код. Скажем Вы догадались, какие SQL плохие, но никак изменить их при проигрывании не можете.
Т.е. не можете оценить общий эффект от их модификации. Нужно менять на производственной системе, еще раз производить захват и проигрывание.

Для оценки производительности можно построить новые индексы, materialized view, можно даже тестироваться на новом patchset (или даже захватить на 10.2.0.4 а проиграсть на 11g) - но вот как работать с SQL планами при этом я не понял.

В заключение: несомненно, крайне полезная опция, несмотря на свою цену и некоторые ограничения при использовании.

Читать дальше...

Announcing Oracle Database 11g

Можно послушать, что говорят ведущие лица компании о выходе 11g. В частности рекомендую послушать, какие новые возможности отмечает Charles Phillips.
Презентации конечно же не технического уровня, но показывают общее направление движения.

Announcing Oracle Database 11g

В целом, как я переговорил с коллегами, 11g имеет не столько инноваций, как скажем, когда выходила 10g. Конечно, с выходом 10g появилось свое clusterware, ASM да прочих новвоведений хватало. Но как показывает практика, освоить их смогли далеко не все. Сейчас же некоторые западные консультанты даже расстраиваются, мол "не о чем говорить" :))) Не совсем так, говорить вполне есть о чем. Но действительно, самое главное, для простых разработчиков - нет революционных изменений. Кроме, пожалуй secure files (замена blob, clob). Мне кажется, это важно для пользователей - продукт становится лучше без коренных изменений. В последнее время я часто слышал жалобы, что от версии к версии одни направления начинаются, другие прекращаются. В 11g этого практически нет.

Есть (и достаточно много) улучшений. Одно из самых востребованных - это механизмы стабилизации планов запросов - SQL Plan management. Это когда новый план вашего запроса будет применяться, только если его подтвердит Ваш DBA.

Конечно есть и real native compilation (теперь не нужен внешний компилятор, в ядре Oracle есть свой кросс-платформенный), появился hierarchical profiler - но этот не как не затрагивает Ваш когд, если он успешно работатает на 10g.

Для администраторов кол-во улучшений гораздо больше. Требуется достаточно больше время, чтобы это освоить. Достаточно упомянуть Fault Diagnostic Automation - что сразу несколько меняет подход к управлению БД. А уж сколько изменнений в advisor в database control - вооще сразу не сосчитать.

Хочу попробовать сразу ответить на вопрос: может не стоит переходить с 9i на 10g, а сразу на 11g ?
Мне кажется, что не стоит ждать. 10.2.0.3 - весьма стабильный патчсет. А как шутят в среде IT, только 3 версия продукта начинает работать стабильно (кстати так было с Oracle 3 и Windows 3.0 :)))) Когда еще выйдет 3 патчет для 11, совсем не известно. Так что мигрируйте на 10g уже сейчас.


Переход на 11.1 будет возможен с 9.2.0.4 или выше. 10.1.0.1 или выше, 10.2.0.1 или выше.

Читать дальше...

Build Your Own Oracle RAC Cluster on Solaris 10 and iSCSI

Just for fun:
Build Your Own Oracle RAC Cluster on Solaris 10 and iSCSI

Читать дальше...

11 roadshow, part 3

Top N best feature:

Для кластера:

- ускорили. улучшили.
- ADDM в кластере работает на глобальном уровне (с отдельными AWR)
- на 70% увеличили производительность в read -only тесте
- ускорили чтения с диска

Вввод-Вывод:

- В ASM сделали возможность выбрать предпочитаемую дисковую группу (для extented cluster'ов)
- Можно поставить свой MAX_IO_SIZE !? (наконец закончилась эта магия 1mb)

- SQL query result cache дает около 25% прироста производительности (в реальных ситуации)
- Обещают что query result cache будет работать между нодами кластера

- для OCI клиентов поддерживает локальный кеш (инвалидация работает на механизме (change notification in bound connection на клиента)

Оптимизатор:

- Новые планы (скажем после сбора статистики) не будет выполняться, пока их не подтвердит DBA.
Удобно, скажем в момент миграции 10g -> 11g обещают что по умолчанию начнут работать теже планы что и в 10g
- Просто зуб дают что теперь auto_sample_size заработал нормально. Вроде бы можно собрать статистику и затем медленно разглядывать как изменяться планы. Как точно пока не знаю.

Читать дальше...

11 roadshow, part 2

Различные наблюдения:

- RBO все таки здесь (кажется он с нами с 10.2)
- statspack также с нами
- Outlines тоже здесь но уже рекомендуют заменить на SQL Plan Management
- alert file теперь в XML формате ! (теперь его смотрят командой adrci !!! :(( )

Читать дальше...

11g roadshow, part 1

За несколько дней до официального представления 11g любимая корпорация решила провести обучение сотрудников новым возможностям 11g.


Первый день в целом маркетинговый. Рассказали про предполагаемые цены/пакеты:

Oracle Real Application Testing Option (SQL Replay) - $10K CPU

• Includes restricted use of SQL Tuning Set capability from Tuning Pack
• Advanced capabilities (Performance Analysis for Replay and Auto SQL Tuning for SPA) provided via Diagnostic and Tuning Packs

Oracle Advanced Compression Option - $10K CPU

• Compression for OLTP (Compression for DW already in EE) - SQL>create table compress for all operations
  
• Secure Files compression and de-duplication
  
• DataGuard Network compression
• Data Pump compression
• Fast RMAN compression

Oracle Total Recall Option - $5K CPU

• Flashback Data Archive

Oracle Business Intelligence Suite Standard Edition One - Pricing $1000 per user
Min = 5 Max = 50

• Oracle Database SE1 – 2 CPU
• Warehouse Builder
• BI Server
• Answers
• Dashboards
• BI Publisher

11g countdown:

Читать дальше...