Oracle on Power

Прошло первое событие из серии Oracle on Power. Пришло 77 человек. Задавали вопросы, делились собственными знаниями - мне понравилось. Мы делали живые демо - как всегда не все шло гладко - но вроде все получилось в конце концов.

Для меня событие началось еще вчера вечером со звонка инженера из центра Montpellier - мол, давай, надо тестировать демо. Подготовка всего вечером накануне мероприятия становится доброй традицией. Установили VPN, применили напильник, прошли сценарий, - все работает. Заработало и на семинаре - я показывал Live Partition Mobility одного из узлов RAC с хоста на Power 6 на хост с Power 7. Все on-line. Swingbecnh ничего почти и не заметил. Слушатели хором подсказывали мне как работать с HMC консолью -))

Cлухи о кончине центра Montpellier сильно преувеличины, все работает и даже развивается. Они готовят еще демонстрации, ну а я постараюсь их здесь показывать. В глубоких планах - позвать их сюда к нам, с семинаром про RAC.

Таким образом у нас есть демо стенд здесь, в ICC центре, в Москве и VPN в Montpellier. Можем тестироваться -)

Мне лично понравилось выступление Алексея Перевозчикова, а конкретно про turbo-core, постараюсь написать про это отдельно. Юра Степанов упомянул интересную деталь, что в машинах с большим количеством процессоров рекомендуют уменьшать SMT c 4-х до 2-х. Буду потихоньку разбираться. У меня не заработал Orion, скачанный с otn. Из зала сказали что надо было взять его из дистрибутива -)

Ссылка на материалы, по старой традиции пароль сообщался на мероприятии -)
Форум

Update 1. В архиве нашлись ошибки - извините - архив был обновлен. Если вы уже скачали, скачивать заново смысла нет. 
Update 2. Рекомендую прочитать презентацию Илья Деева про псевдосекционирование, которую Илья делал для RuOUG.

Update 3. Отзывы:

"Как ни странно содержание докладов соответствовало заявленной теме"

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

Are YOU ready?

Тем, кто не смотрит прямую трансляцию королевской свадьбы принца Уильяма и Кейт Миддлтон Ваш английский джентельмен предлагает посмотреть классное маркетинговое видео про Exadata. Мне понравились там некоторые мертики и смелые сравнения. По дизайну чем-то напоминает пост про пищу для размышления.

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

FUD: Fear, Uncertainty and Doubt

В 2004 году, когда Oraсle только выпустил 10g я провел несколько десятков презентаций "Введение в Oracle Enterprise Grid", которая, как всегда, начиналась "издалека". Я рассказывал о том, что давным-давно, когда я еще не родился на свет, единственным серьезным игроком на рынке IT была компания IBM. Еще не было Oracle, не было Microsoft и еще никто не мог утереть нос голубому гиганту.

В 1964 году в компании IBM был изобретен первый mainframe. Компьютер, на котором эта компания построила свое будущее. Человека, которые изобрел первый mainframe, и возглавлял ключевую группу инженеров, звали Gene Amdahl. Интересно, что через некоторое время после изобретения mainframe, Gene Amdahl ушел из IBM и оcновал собственную компанию Amdahl Corp. Как мы знаем, хорошие инженеры долго не засиживаются на одном месте :^). Так вот, Джин Эмдал ушел со своей прекрасной, высоокооплачиваемой позиции в IBM, чтобы создать свои собственную компанию. Смелый шаг и редкое явления для 60-х годов. И сделал он это только для того, чтобы разработать еще более крутой компьютер, чем mainframe. И тут началась гонка. Гонка по созданию все более и более мощных серверов. В гонку включились все игроки IT и борьба пошла не на жизнь а на смерть. Дальше я рассказывал, сами понимаете, про RAC :^)

Но сейчас я про другую часть этой истории. Когда Джин Эмдал ушел из IBM, и фактически начал конкурировать с голубым гигантом, он столкнулся с интерсным феноменом, который он определил как FUD (Fear, Uncertainty, Doubt). Феномен заключался в том, что сейлы IBM, впервые столкнувшить с реальной конкуренцией, начали распространять среди заказчиков неподкрепленную реальными фактами дезинформацию о продуктах Amdahl Corp., а именно элементы страха (fear), неуверенности (uncertainty) и сомнений (doubts) или попросту говоря FUD.

Классический пример FUD можно почитать в моем комментарии к посту "про золушку-2", где я пишу про некачественный опто-изолятор 4N25, который в любой момент может оставить материнскую плату большого компьютера без питания. Мы сталкиваемся с FUD, когда сейл говорит: "Не покупайте эти сервера компании XXX, так как они часто ломаются", но при этом не подкрепляет информацию реальными фактами.

Еще примеры: "это плохой продукт, так как он делается на заводе в Китае", "а что будет, если с Китаем начнется война? Вы хоть понимаете какой Вы на себя берете риск?" или "заводы Fujistu расположены в Японии, а там часто бывают землетрясения", "если в компьютере не дублированы все PCI-карты то он не надежен", "эти сервера радиоактивные", и т.д. В общем, не полностью обоснованные утверждения, направленные на внедрение в мозг заказчика неуверенности, сомнений и страха быть уволенным за покупку некачественного товара :^)

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

is Oracle the Apple ?

Нашел весьма занятный отчет IDC на сайте Oracle. Не очень сложный английский, можно прочитать. Занятный термин oServer (сравните с iPad) -). Весьма положительный для Oracle  отчет, где  Exadata и Exalogic представлены как революционные продукты, почти такие же как  продукты Apple -) Все так (я про Exadata), спору нет. Вот только ...кажется мне что атака  на HP (вы помните про Itanium ?) она уж как совпала по времени с попытками прорваться на рынок  Intel систем. Насколько я понимаю на этом рынке HP сейчас лидер. A если так, Oracle решил серьезно прорываться на рынок  с Intel решениями...то зачем тогда нужны M-series ? Ведь невозможно уже сейчас объяснить заказчику что лучше - M9000 или Exadata (на самом деле конечно можно, но маркетинг специально этого не делает). Конечно объявлен Exalogic на T3-1B, это настоящий SPARC, спору нет, но ..это не M-Series. Что-то мне подсказывает, что Ларри понравились T3/T4 машинки, а вот M-ки в улучшем случае будет проданы,  в худшем просто остановлены. Очень соглашение с Fujitsu напоминает начало конца (продаж)...В общем то купить Sun чтобы построить затем бизнес на Intel + внутренние SATA диски ход гениальный -))) Никто ничего не понимает, можно продавать что хочешь -).  Итак, поскольку ставка в любом случае ставиться на небольшие серверы - RAC наше все, как и пытались мы с Сергеем Даниловым вам внушить все это время.
Совсем заболтался и забыл ради чего я все это написал - сегодня же день рождения опции Real Application Clusters и Сергея Данилова !   Сергей, поздравляю !

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

statspack discrepancy

Получив очередной statspack я с удивлением обнаружил следующее сообщение:

Note: There is a 50% discrepancy between the OS Stat total CPU time and
      the total CPU time estimated by Statspack
          OS Stat CPU time: 1209725(s) (BUSY_TIME + IDLE_TIME)
        Statspack CPU time: 2419488(s) (Elapsed time * num CPUs in end snap)

Jonathan Lewis (я безусловно рекомендую прочитать все его статьи про statspack) приводит замечательный пример, когда такое возможно:  например  CPU  intensive процедура не завершилась ко времени снимка statspack.   В этом случае время OS time >  чем Statspack CPU time, потому что время считается только для завершившихся запросов.  Однако в моем случае все наоборот:  OS time <  Statspack time !  Надо отметить, что   =  2419488 / 1209725 =  2.000031412097791. Хорошая такая точность, до 4 знака после запятой.

Как репортит statspack, мы имеем дело с  Oracle 10.2.0.4.0,   Num CPUs:   96

Однако nmon - наше все (если у нас AIX). И он нам сообщает что на нашей машине Power 595 у нас всего 48 активных процессоров и SMT выключено (я так думаю, в противном  случае  вкладка CPU_ALL содержала бы примечание про SMT, а его нет в этом случае).  Я предполагаю, что  Oracle в данном случае ошибочно считает, что SMT всегда включено.   

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

COOPERTITION

В 2006 году меня попросили сделать презентацию в офисе IBM на открытии совместного мероприятия IBM-Oracle и я начал презентацию вот с этого слайда. Это одно слово (COOPERation и одноврменно compeTITION) как нельзя точно передает отношения между двумя компаниями. С одной стороны конкуренция, с другой кооперация. На момент проведения презентации конкретно в России было 424 совместных заказчика IBM-Oracle, которые использовали СУБД Oraсle на технике IBM. Эти крупнейшие заказчики представлены во всех секторах от Public Sector до Commercial.

Реальность современного IT рынка состоит в том, что, конкурирующие между собой вендоры часто оказываются в ситуации, когда они сами и их продукты должны работать совместно ради создания у Заказчика бизнес-критичного решения. В таких случаях оба вендора больше потеряют, чем приобретут, если на какой-то момент позволят стратегическому соперничеству взять верх над тактической кооперацией. Именно поэтому в IBM и в Oracle существуют люди, работающие над совместными решениями не смотря на усиливающуюся конкуренцию и эта реальность не изменится.

Несмотря на то, что при покупке Sun элемент compeTITION усилился, у компаний есть совместный центр тестирования в Montpellier, France (фотографии копирайт Дмитрия Волкова), где работают несколько десятков человек над тестированием и обкаткой совместных решений Oracle-IBM и которые буквально получают зарплату из рук обоих компаний одновременно. Заказчики могут приехать в центр, протестировать софт, выпить чашечку кофе и полюбоваться Лазурным Берегом. Мой отъезд в Oracle UK был освещен достаточно ярко на этом блоге, а отъезд Дмитрия остался как-то в тени. Так вот, Дмитрий работает в одной из групп IBM, которые занимаются совместными решениями "техника IBM под СУБД Oracle". До Montpellier Дмитрий не доехал -- он базируется в московском офисе IBM.

Поэтому в этом блоге (похоже, что теперь уникальном блоге Oracle/IBM) Вы видите весьма интересные метаморфозы (по биологии проходил давно еще :^) . Большая просьба не искать в этом блоге какой-либо политики -- ее тут нету. Любой заинтересованный человек может оставить комментарий. Я конечно иногда обожаю оставлять всякие гадостные комментарии (чтобы никого сильно не метаморфозило), но это я так, любя :^)

Как Вы уже наверное читали ниже в постах "читая TPC-C" и "core factor", помогая Заказчикам осознавать value железа IBM POWER Дмитрий на самом деле автоматически помогает Oracle продвигать Oracle Database (да еще с каким коэффициентом core factor!), поэтому я лично вижу совместную выгоду для обоих компаний :^)

P.S. Если кто-то не понимает происходящего на блоге, то всегда можно задать вопрос.

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

про золушку-2

Вы про золушку помните ?  И были это еще не ее беды.. По первой же попавшейся ссылке мы читаем из чего состоит database cell:
   * X4275 Server
   * 2 Quad-Core Intel® Xeon® E5540 Processors
   * 24GB RAM
   * Dual-port 4X QDR (40Gb/s) InfiniBand card

Перечитываем еще раз и убеждаемся что карта Infiniband ..одна, только двухпортовая. Повторю - это обычная PCI -E карточка, стоимостью $2,295. Что удивительно, так то,  что ничего не мешает нам поставить их две, это поддерживается. Инженеры Sun обо всем подумали проектируя X4275. Теперь внимание вопрос - что произойдет если у системы за $300K за железо  +  $360K за специальное ПО сгорит 1 карточка за $2K?  Да в общем ничего, вы же помните что данные задублированы причем обязательно на других  cell. Потеря 1/3 производительности ? Потеря данных, если за до замены карточки  сгорит диск ? Весьма сложная ребалансировка когда карточку заменят ? Who care about... Как же это могло произойти, почему всего одна?   Я честно говоря не понимаю (есть  версия - просто закончились свободные порты).  Но знаю точно, что это совершенно бессмысленная и беспощадная экономия $2K. Кстати купить за свои деньги и доставить - нельзя -). Остается только молиться.  Enjoy !

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

Апрель

Прошло время, есть изменения по этому тексту:

В Апреле состоится несколько интересных, на мой взгляд, событий :

• 20,  (а не 18 как я писал раньше) будет проводиться RuOUG. Бесплатно при условии членства в RuOUG. Если вы забыли зарегистироваться, наверно еще можно написать на welcome@ruoug.org чтобы спросить что Вам делать. Программа семинара.
• c 18 по 20 апреля В мае  в партнерской академии Oracle будет проводиться очень интересный семинар под пока кодовым названием 'RAC is Simple'.  За 3 дня вас научат как поставить и протестировать RAC 11gR2 на платформе Linux, как перенести приложение, как мигрировать с single instance. Вам предложат более 10 лабораторных работ на виртуальных машинах.   Это платный семинар, стоимость около $60 в день. Все детали лучше выяснять у партнерской академии.
  
• 29 апреля состоится очередной технологический клуб Power, в этот раз посвященный работе Oracle на платформе Power. Программа. Ссылка на регистрацию.

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

service as is

Отмазка: предлагаемый сервис ограничен по времени, не предполагает выполнения каких-либо работ в ограниченный срок и представляется AS IS безо всяких  всяких гарантий. 

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

911

Если при установке AIX ввести в качестве опции установки 911 (а не то что перечислено на экране), то волшебным образом установка перейдет в режим отладки и вы сможете увидеть детальный лог. Мне просто нравится, когда инженеры продолжают вставлять чит-коды даже в казалось бы   очень серьезные программы  -))

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

core factor

После прочтения core factors table каждому разумному человеку становиться понятно, что Oracle стоит покупать только на SPARC T3 процессор из-за коэффициента 0.25. И все крики что не не все процессоры одинаково полезны сталкиваются с "а докажите !". Доказать, это кстати интересное упражнение -).

Начну издалека: во первых, лично я ненавижу разговоры о БД на серии T из-за того что они ...были сделаны для Web серверов, и только потом появилась (я уверен что в маркетинге) идея запихивать их под БД тоже. Собственный тест на еще на T1 показал мне что так оно и есть. По моему убеждению Intel Xeon порвет T2/T3 под нагрузкой БД. 4 сокета максимум в T3 тоже не добавляют оптимизма. Борорься с Intel на 4-х сокетах сейчас очень не просто даже настоящим RISC. Что не вовсе не умоляет иженерных достоинств T3, в том числе весьма достойной виртуализации. Во-вторых, мне кажется странным, что Oracle решил вот так просто отдавать что-то дешевле. Не верю, что за счет весьма стабильного бизнеса СУБД решили поднимать производство T3. Я хочу показать, что причина тут в другом.
Все, пора показать данные:

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

STU.Part 3

На мероприятии мне удалось побывать на ..лекциях по тому как работает Unix. Мне они очень понравились, хотя и не все оказалось понятно. Читал их волшебный дядька, который сделал из скучной в общем то темы целый концерт и вызвал желание разобраться/вспомнить некоторые вещи. Например он сказал что в качестве первого шага для того чтобы понять что происходит, он запускает vmstat. Тут одна проблема, вывод vmstat очень сложно понимать, он требует реальных знаний данной ОС. В качестве примера приведу колонку %wait for IO. В Linux сейчас эта колонка называется wa.Читаем man и видим:
"wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle"
Так вот дядька и сказал, что не нулевой Wait for IO не говорит о проблемах с I/O, а также нулевой I/O не гарантирует, что их нет. Что за колонка такая по которой ничего сказать нельзя -) ? Для начала, что нам хотел сказать man: на самом деле процессор не тратит реального времени на ожидания ввода-вывода, и если ему есть что делать то он занимается реальной работой, отвлекаясь по прерываниям чтобы посмотреть не пришли ли ему данные с устройства. Поясню еще - если процесс блокируется в ожидании ввода-вывода, то дальше идти он не может. Но возможно в системе есть и другие процессы которым нужно процессорное время. Поэтому, если у нас загруженная система, то Wait for IO может быть близким к 0, независимо от от объема ввода-вывода. С другой стороны, если системе делать нечего, то время которое процессор провел в ожидании реального ввода-вывода будет зафиксировано не в idle а в wa.
Даже это (как мне кажется разумное) объяснение не отвечает на вопрос - куда смотреть то чтобы понять есть проблемы с вводом - выводом или нет ? Похоже что для начала нужно смотреть в колонку b - blocked for IO (это я так думаю), а вот что думает man Linux:
"b: The number of processes in uninterruptible sleep."
а документация AIX: "This includes threads that are waiting on filesystem I/O or threads that have been suspended due to memory load control." Что же смотреть в колонке b ? если там постоянно больше процессов чем у вас устройств ввода-вывода (дисков или путей) - это знак. Скорее всего, да - все такие проблемы найдутся.
По моим воспоминаниям, на Solaris был магический барьер - если wait for IO больше 40%, то ищи проблем с вводом выводом, если меньше - то скорее их не найдешь. Число магическое, объяснить я его никак не могу. Конечно же окончательный диагноз дает iostat с service time (<10 ms отлично, больше 100ms все уже умерли) и средней длиной очереди на устройство.

Ну и напоследок, когда я подешел к дядьке и спросил в чем по его мнению разница между swapping и paging, он стал кричать на меня что такого слова swapping нет вообще -) Наверно поэтому она не встречается в описании команды vmstat на AIX, а на Linux (и Solaris) есть цельные колонки -)). На дальше всех пошли пижоны из Apple и я не нашел vmstat на Mac, а vm_stat вообще не содержит колонок, а которых я писал -))

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

STU.Part 2

Оперативной памяти почти всегда не хватает если у Вас есть база данных.  Поэтому инженеры начали борьбу за то чтобы ее стало больше -)

На сегодня существует два подхода:

Если у Вас Solaris или Linux (кто бы сомневался в таком ограничении) то вы можете использовать Smart Flash Cache – если очень коротко, то это кэш второго уровня (L2) для Buffer Cache.   Чтобы влючить эту возможность вам понадобится установить параметры db_flash_cache_file (указать устройство) и db_flash_cache_size (указать размер).  Конечно устройство должно быть быстрее наших дисков и поэтому предполагается использовать solid state storage devices.  Подождите, даже SSD  нам придется поставить не один, потому что один диск  скорее всего  не вытянет нужную нам производительность !
Дальше читая документацию мы находим фразу  “can improve response time for read intensive OLTP application”. Мне кажется что это ключевой момент, потому что если приложение write intensive то этот механизм может сделать даже хуже.

Все равно, отличная инженерная идея !  L2 кэш давно  используется при разработке процессоров и пора уже было давно сделать что-нибудь подобное.  К сожалению, даже после прочтения этого поста я не понял как это работает
 - каков алгоритм вытеснения из памяти во  FC
-  скорее всего процесс если ему нужны данные и они во FC считывает их и они попадают обратно во buffer cache. Но так ли это ?

Теперь перечитайте этот пост сначала – все это волшебство только для Solaris и Linux.
Инженеры IBM нанесли ответный удар – технология называется Active Memory Expansion. Они предложили .. сжимать страницы основной памяти, но не все конечно, а какую-то их часть (дальше я предполагаю что и не все типы страниц памяти сжимаются). Для приложения эта технология абсолютна прозрачна и приложения просто видят больше памяти, чем физически есть на машине.

После запуска специальной команды awepat вы сможете увидеть (если у Вас AIX 6 или 7 и машина класса 750 или выше)

True Memory                    : 1.00 GB

SMT Threads                    : 4

Active Memory Expansion        : Enabled

Target Expanded Memory Size    : 1.50 GB

Target Memory Expansion factor : 1.60

Что в моей системе (LPAR) только 1 Gb физической памяти, которая превратилась в 1.5 Gb видимой приложению. Постойте, но чтобы сжимать память нам нужна процессорная мощность?  Да, конечно и поэтому в следующем разделе awepat вы видите

Expansion    Modeled True      Modeled              CPU Usage

Factor       Memory Size       Memory Gain          Estimate

---------    -------------     ------------------   -----------

     1.00          1.50 GB         0.00 KB [  0%]   0.00 [  0%]

     1.20          1.25 GB       256.00 MB [ 20%]   0.00 [  0%]

     1.60          1.00 GB       512.00 MB [ 50%]   0.18 [ 18%] << CURRENT CONFIG

что доп 512 Mb памяти нам будут стоить  18% от одного  ядра. Нагрузка эта распределяется между всеми ядрами LPAR. Посмотреть % реальной занятости ядер обслуживанием этого механизма  можно с помощью lparstat -c.  Сколько же нам попросить доп памяти по отношению к основной чтобы не убить процессоры ?   По оценкам инженеров пока рекомендуется использовать Expansion factor в районе 1.2 – 1.5.

Два дополнительных замечания:
- все таки это новая возможность и пока рекомендуется ее использовать для test & dev.
- попробовать эту возможность можно совершенно бесплатно и легально в течении 60 дней, ничего покупать не нужно -). А вот дальше придется доплатить, но конечно меньше чем за реальную память.
Как вы видите, теперь ответить на вопрос а сколько у меня памяти отведено  под Oracle весьма непросто. Скажу больше, что на AIX с учетом Active Memory Expantion & Active Memory Sharing вывод команды vmstat может довести до истерики -))) Но об этом на семинаре 29 апреля -)

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

STU.Part 1

Пока Игорь Мельников собирал по деревням Шотландии DataPump файлы, мне повезло попасть на Oracle Open World IBM System Technical University.  Первым делом я поинтересовался где у них тут наш Рачок. К удивлению не только не набили морду, но и ...показали как узел RAC переезжает с сервера c Power 6 процессорами на сервер c Power 7 без остановки. Называется эта технология Partition Live Mobility (PLM). Все что пришлось подготовить на новой машине с Power 7 процессорами - это сконфигурить пути, чтобы переехавший узел смог увидеть voting диски и собственно базу.  Из видео (хотя видно плохо) видно что транзации на всем кластере замерли буквально на секунду и продолжили раньше. Никакие механизмы FAN или TAF тут не работали -  PLM background скопировал память, затем остановил Partition на одном сервере и тут же поднял на другом. TCP/IP соединения не разрывались. Остановка на секунду была очевидно из-за cluster freeze - в момент переезда кластер подумал уж не отвалились ли нода, но потом удачно вернул ее обратно. Конечно эта демонстрация была не вполне честной, по честному было необходимо остановить узел, но ковбойский метод сработал.

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

Datapump in RAC

При импорте или экспорте данных в среде RAC возникает проблема расположения файлов дампов. Они должны быть "видны" всем узлам кластера. Есть конечно возможность положить dmp-файлы на локальный диск одного узла, и далее установить некластерный режим работы Datapump: параметр CLUSTER=N утилит expdp и impdp, либо через параметр SERVICE_NAME=<имя сервиса>.
Где "имя сервиса" - сервис жестко "привязанный" только к одной ноде.

Но если файлы дампов для импорта занимают около 1Тб (уже сжаты с помощью Advanced Compression), и на локальных дисках мало свободного пространства?
Да и объем данных большой, и хотелось бы для импорта использовать все узлы кластера.
В случае Exadata Database Machine именно так и происходит ...

Но у нас есть возможность хранить dmp-файлы DataPump прямо на ASM !
Осталось только перед импортом скопировать dmp-файлы в отдельный каталог на дисковой группе ASM.

Сказано - сделано.
1. Создаем шаблон на ASM для хранения dmp-файлов (отключаем зеркалирование - для экономии места и располагаем файлы на внутренних дорожках диска):

ALTER DISKGROUP FRA ADD TEMPLATE my_dpdump_template ATTRIBUTES (UNPROTECTED COLD FINE); 

2. Создаем каталог на ASM для хранения dmp-файлов:

ALTER DISKGROUP FRA ADD DIRECTORY '+FRA/orcl/dpdump';

3. Создаем каталог (объект directory) в БД:

 CREATE OR REPLACE DIRECTORY MY_DUMP_DIR as '+FRA(my_dpdump_template)/orcl/dpdump';

обратите внимание, что для файлов каталога используется созданный на 1-ом шаге шаблон.

4. Теперь можно скопировать в этот каталог файл с помощью утилиты asmcmd (/u01/dump - это промежуточный каталог на локальном диске узла):

ASMCMD> cd +FRA/orcl/dpdump
ASMCMD> cp /u01/dump/appfull01.dmp ./
copying /u01/dump/appfull01.dmp -> +FRA/orcl/dpdump/appfull01.dmp
ASMCMD> ls -l
Type     Redund  Striped  Time             Sys  Name
                                           N    appfull01.dmp => +FRA/ASM/DUMPSET/appfull01.dmp.260.747620627

как видите реально в каталоге dpdump присутствует ссылка на файл +FRA/ASM/DUMPSET.
Все правильно, но почему в каталоге ASM, а не orcl ?
Утилита asmcmd работает от имени экземпляра ASM и не знает к какому экземпляру относится ваш файл !
И так просто переложить его в правильное место (+FRA/orcl/dumpset) не получится ...

Выход простой: для копирования dmp-файлов нужно использовать пакет dbms_file_transfer:

create or replace directory MY_SRC_DIR  as '/u01/dump';
begin
  dbms_file_transfer.copy_file(source_directory_object      => 'MY_SRC_DIR',
                               source_file_name             => 'appfull01.dmp',
                               destination_directory_object => 'MY_DUMP_DIR',
                               destination_file_name        => 'appfull01.dmp');
end;
/

Теперь все нормально:

ASMCMD> cd +FRA/orcl/dpdump
ASMCMD> ls -l
Type     Redund  Striped  Time             Sys  Name
                                           N    appfull01.dmp => +FRA/ORCL/DUMPSET/COPY_FILE_0_0.260.747621645
ASMCMD> 

Обратите внимание что системное имя файла на ASM теперь имеет другой "говорящий" вид.

Дальше осталось автоматизировать этот процесс для всех файлов dumpset-а, то есть написать скрипт для правильного копирования всех файлов дампа...

На фотографии запечатлен процесс импорта данных на Exadata X2-8 в центре тестирования в г.Линлитгоу, Шотландия (Linlithgow, Scotland), зеленые лампочки ячеек хранения очень красиво переливаются. :-)

После завершения импорта и построения индексов - БД заняла на дисках ~10Тб, и началось тестирование. Но это уже другая история ...

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

Oracle Database 11g R2 XE Beta

Oracle Database 11g R2 (11.2.0.2) Express Edition Beta уже доступен для скачивания!

Документация доступна по этой ссылке.

Oracle Database 11g XE доступен только для двух платформ: Linux x64 и Windows x86.
Все ограничения остались прежними кроме одного: размер БД может занимать 11Gb, а не 4Gb как в предыдущем релизе.

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

Все на System z !

Wow ! 11gR2 выпустили на System Z !  Поскольку по времени это совпало с объявлением про Intanium то очевидно рекомендация Oracle для владельцев Intanium - это System z, не так ли   ?

Update 1. Mama mia ! "each Oracle ACE will receive a half-rack Exadata and Exalogic package for their labs" !

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