|
|
|||||||||||||||||||||||||||||
|
Мой первый день с сервером Oracle Database 10g Release 2Источник: Oracle Magazine
Источник: журнал Oracle Magazine, September-October 2005 Наш эксперт рассказывает о своем первом опыте работы с сервером базы данных Oracle Database 10 g Release 2. Вопрос. Можете ли вы рассказать нам о вашем опыте работы с сервером Oracle Database 10g Release 2 и показать некоторые из его важных новых функциональных возможностей? Ответ. Во-первых, в этой колонке мы даже не будем пытаться охватить все новое в сервере Oracle Database 10 g Release 2 - это невозможно изложить на нескольких страницах. ( Прим. пер .: см. также технический документ "Top Ten Things About Oracle Database 10g Release 2", написанный Томом с соавтором Кэри Миллсапом (Cary Millsap, http://www.hotsos.com/). Некоторые дополнительные детали можно найти в серии публикаций " Наиболее важные возможности для АБД Oracle Database 10g: Выпуск 2 - Дополнительные свойства ".) Более подробную информацию см. в руководстве Oracle Database 10g Release 2 New Features Guide (ссылка приведена во врезке Следующие шаги ). Я же изложу здесь то, на что обратил внимание и счел полезным для вас. Автотрассировка (autotrace) За первую пару минут использования сервера Oracle Database 10 g Release 2 я сразу же обнаружил это усовершенствование (см. листинг 1). В механизме автотрассировки для вывода на экран планов выполнения теперь используется пакет DBMS_XPLAN. Это позволяет получать намного более детализированные планы по сравнению с предыдущими версиями сервера базы данных. Мы могли получать такие планы в сервере Oracle9 i Database Release 2 и выше с помощью поставляемого пакета DBMS_XPLAN, но использование этого пакета механизмом автотрассировки существенно упрощает их получение. Особенно отметим, информация о предикатах внизу плана выполнения точно показывает, на каких шагах сервер Oracle Database применяет их. Здорово.
Условная компиляция (conditional compilation) В языке PL/SQL появилось много новых возможностей. Первой вещью, на которую я обратил внимание, была условная компиляция; это то, что отсутствовало у меня с тех пор, когда я был программистом на языке C. Условная компиляция позволяет заставить компилятор игнорировать код (или не игнорировать). Возможно, сначала это не кажется слишком полезным, но ... С условной компиляцией:
На листинге 2 показан быстрый пример, что представляет из себя условная компиляция и как она работает.
Обратите внимание, что без определения значения $$debug_code "отладочный" код не печатается и не компилируется: SQL> exec p А наш реальный код - здесь PL/SQL procedure successfully completed. Просто активируя переменную debug_code (как это показано ниже), мы активируем отладочный код. Обратите внимание, "debug_code" - заданное мной имя, а не какое-то специальное имя; вы по желанию можете определять свои собственные переменные. SQL> alter procedure P compile 2 plsql_ccflags = 'debug_code:true' reuse settings; Procedure altered. SQL> exec p Наш отладочный код будет размещен здесь А наш реальный код - здесь PL/SQL procedure successfully completed. Пакет DBMS_OUTPUT Пакет DBMS_OUTPUT модернизирован в сервере Oracle Database 10 g Release 2. Вы не только можете задавать неограниченный (unlimited) размер буфера (нет больше ограничения в 1 000 000 байтов!), но вы также можете печатать строки, длина которых намного превышает 255 символов. Предельная длина строки теперь равна 32K. Продемонстрируем эту модернизацию: SQL> set serveroutput on - > size unlimited SQL> begin 2 dbms_output.put_line 3 ( rpad('*',2000,'*') ); 4 end; 5 / ************************ ... ************************ PL/SQL procedure successfully completed. Быстрый аварийный переход на резервный ресурс (Oracle Fast-Start Failover) Другая новая функциональная возможность в сервере Oracle Database 10 g Release 2 - автоматический аварийный переход на резервную базу данных. Теперь в случае сбоя сервера основной базы данных, устройств хранения или сети технология Oracle Data Guard позволяет автоматически перейти на работу с резервной базой данных - не нужен человек, выполняющий последовательность команд или нажимающий на кнопки. Перенос баз данных (database transports) В сервере Oracle Database 10 g Release 1 были введены табличные пространства с межплатформенной переносимостью (cross-platform transportable tablespaces), а в сервере Oracle Database 10 g Release 2 все это переходит на следующий уровень. Теперь вы можете переносить всю базу данных на платформы, которые используют одинаковый порядок следования байтов (endianess). Это означает, что вы можете переносить всю базу данных (а не только отдельные табличные пространства) с платформы HP-UX на платформу Apple Macintosh или с платформы Open VMS на платформу Solaris x86. Нет больше никаких дампов и перезагрузок. Сжатие в утилитах Data Pump (data pump compression) Когда вышел сервер Oracle Database 10 g Release 1, хорошей новостью было то, что утилиты экспорта (EXP) и импорта (IMP) были полностью переписаны и появились новые утилиты Oracle Data Pump - EXPDP и IMPDP соответственно. Утилиты EXPDP и IMPDP имели один недостаток - во время процесса экспорта невозможно было сжимать DMP-файлы. Используя утилиту экспорта EXPDP, вы должны были сначала создать DMP-файл и лишь затем сжать его (в отличие от процесса со старой утилитой экспорта EXP, который мог писать в именованный канал (named pipe) данные, сжимаемые в нем на этом же шаге). К счастью, в сервере Oracle Database 10 g Release 2 облегчено создание и сжатие DMP-файлов, даже по сравнению со старыми утилитами. Утилита EXPDP теперь сама сжимает файлы, а утилита IMPDP автоматически восстанавливает сжатые данные - исчезла "возня" на уровне операционной системы. И сервер Oracle Database 10 g Release 2 на платформе Windows впервые может сжимать DMP-файлы "на ходу" (именованные каналы - функциональная возможность платформ UNIX/Linux). Асинхронная фиксация транзакций (asynchronous commit) Обычно, когда приложения на языках Java, C или Visual Basic выполняют оператор COMMIT, они должны ждать, в частности, завершения события ожидания "log file sync" (синхронизация журнальных файлов). Это ожидание происходит из-за того, что клиент ждет, когда процесс записи в журнал (log writer process) сбросит на диск журнальную информацию, чтобы сделать транзакцию постоянной (permanent), обеспечивая сохраняемость данных. Обычно это то, что вы и хотите. Когда вы выполняете оператор COMMIT, все изменения, сделанные в транзакции становятся постоянным. Однако нет правил без исключений. Как насчет системы, которая должна как можно быстрее обрабатывать записи, поступающие, возможно, от датчиков или из сети? Цель этой программы в реальности состоит в том, чтобы сформировать пакет из нескольких записей, вставить их в базу данных оператором INSERT, зафиксировать эту вставку оператором COMMIT (чтобы сделать записи видимыми) и продолжить свою работу дальше. Ей действительно не нужно ждать фиксации транзакции; фактически, наличие ожиданий не позволяет этой программе работать с такой скоростью, с какой она может. В сервере Oracle Database 10 g Release 2 появилась асинхронная фиксация транзакций. Мы теперь можем сказать: "фиксируй, но не жди" (commit, but don't wait) или "фиксируй и, пожалуйста, жди" (commit, and please do wait). Но если вы используете способ "фиксируй, но в режиме без ожидания", вы должны быть готовы к тому, что в некоторый момент времени в будущем данные, которые были "зафиксированы", будут потерянны. Если вы фиксируете транзакцию, но не ждете, и в системе происходит сбой, данные могут оказаться незафиксированными. Только вы можете решить, приемлемо ли это для вас. Есть много классов приложений (включая программы высокоскоростного "заглатывания" данных), единственная цель которых состоит в том, чтобы включать в базу данных поток данных; для таких приложений режим "фиксируй, но не жди" не только приемлем, но и весьма желателен с точки зрения производительности. Я на языке Java написал небольшой пример, показанный на листинге 3.
Обратите внимание, как на листинге 3 я использую оператор COMMIT: либо COMMIT WORK WRITE BATCH NOWAIT, либо COMMIT WORK WRITE IMMEDIATE WAIT. Первый вариант - новая возможность - фиксация транзакции без ожидания завершения выполнения этой операции. Последний вариант - это способ, который использовался традиционно. Когда я прогнал тестовую программу, показанную на листинге 3 (закомментированный оператор CREATE TABLE (перед оператором INSERT) приведен для справки), с опцией WAIT (с ожиданием), я заметил, что масса времени тратится на ожидание синхронизации журнальных файлов, а при прогоне с опцией NOWAIT (без ожидания) на ожидание фактически не тратится никакого времени. Результаты показаны на листинге 4.
Это различие в программах высокоскоростной загрузки данных, которые во время загрузки должны периодически фиксировать транзакции, будет весьма ощутимым. Прозрачное шифрование данных (transparent data encryption) Теперь о революционной функциональной возможности в сервере Oracle Database 10 g Release 2 - прозрачном шифровании данных. Она позволяет легко и, как говорит ее название, прозрачно шифровать хранимую информацию. Авторизованные пользователи не должны иметь дело с ключами шифрования; данные для них будут расшифроваться (и шифроваться) совершенно прозрачно. Данные хранятся на диске зашифрованными, поэтому даже если кто-то и украдет вашу базу данных, информация будет защищена. Мой опыт работы со средствами прозрачного шифрования данных не позволяет дать вам исчерпывающего примера их использования ("здесь все, что вы можете делать"), а скорее показывает, как настроить эти средства и как вы могли бы использовать их. Первое, что я должен сделать, это - настроить цифровой бумажник (wallet). В нем будут храниться ключи шифрования; этот бумажник защищается паролем. Для моего примера "на скорую руку" я в домашнем каталоге Oracle просто создал каталог "wallet" и в файл sqlnet.ora вставил следующее: WALLET_LOCATION= (SOURCE=(METHOD=FILE) (METHOD_DATA= (DIRECTORY=/home/ora10gr2/wallet) ) ) После этого мне остается только открыть этот бумажник: SQL> alter system 2 set encryption wallet open 3 identified by foobar; System altered. Если вы начали использовать средства прозрачного шифрования, этот оператор необходимо выполнять один раз при каждом запуске экземпляра сервера базы данных, в противном случае ключи шифрования будут недоступны системе, и следовательно, будут недоступны и зашифрованные данные. Теперь, поскольку я еще не создал никаких ключей шифрования, нужно сделать это: SQL> alter system 2 set encryption key 3 identified by foobar; System altered. В этом случае ключ генерирует система, но я мог бы так же просто определить ключ, выбранный мною самим, если бы мне нужно было легко переносить одни и те же данные из одной системы в другую. И это все, что нужно было сделать для настройки. Теперь я готов сохранять зашифрованные данные: SQL> create table t 2 ( c1 varchar2(80), 3 c2 varchar2(80) encrypt ) 4 tablespace test; Table created. SQL> insert into t values 2 ( 'эти_данные_не_зашифрованы', 3 'эти_данные_зашифрованы' ); 1 row created. Эти данные были прозрачно зашифрованы на диске, а при выборке они дешифрируются: SQL> select * 2 from t; C1 C2 ------------------------- ------------ эти_данные_не_зашифрованы эти_данные_зашифрованы Как удостовериться, что эти данные на самом деле зашифрованы? Для поиска этих строк в файле данных Oracle я использовал утилиты strings и grep (утилиты ОС UNIX для поиска в файлах). Сначала я должен гарантировать, что зашифрованные данные записаны на диск: SQL> alter system checkpoint; System altered. А затем я искал эти строки. Я искал в файле данных encrypt.dbf любые строки, в которые входил текст "эти_данные": $ strings -a encrypt.dbf/grep эти_данные эти_данные_не_зашифрованы Как видите, была найдена только строка "эти_данные_не_зашифрованы". Другая строка не видна, потому что перед сохранением она действительно была зашифрована.
Этот быстрый пример показывает только верхушку айсберга этой новой возможности шифрования. Средства прозрачного шифрования данных работают с выводом во внешние таблицы, утилитами Data Pump и т.д., а инструменты с графическими пользовательскими инструментами, такие, как диспетчер бумажников Oracle Wallet Manager, позволяют вам управлять вашим бумажником и паролями. Есть также операторы смены ключей данных, когда вы чувствуете, что эти ключи скомпрометированы. Я полагаю, что прозрачное шифрование данных - одна из наиболее революционных функциональных возможностей сервера Oracle Database 10 g Release 2. Предложение LOG ERRORS В сервере Oracle Database 10 g Release 2 в операторах DELETE, INSERT, MERGE и UPDATE можно использовать новое предложение LOG ERRORS (протоколировать ошибки). Использование этого предложения в операторах массовой обработки данных позволяет записывать строки, при обработке которых произошли ошибки, и не откатывать весь этот оператор. Вы можете выполнить оператор, такой, как INSERT INTO T SELECT A,B,C FROM T2 LOG ERRORS INTO ERRLOG('BAD_ROWS_FOR_T') REJECT LIMIT UNLIMITED. При выполнении этого оператора в таблицу BAD_ROWS_FOR_T (некорректные записи для таблицы Т) будут записываться все строки, которые нарушают ограничения; например, будут протоколироваться ошибки, вызванные слишком большими значениями столбцов, нарушениями ограничений целостности (ограничения NOT NULL, уникальности, ссылочной целостности и проверочные), ошибки, возникающие при выполнении триггеров, ошибки преобразования типа столбца подзапроса к типу соответствующего столбца таблицы, ошибки распределения строк по секциям и некоторые ошибки при выполнении оператора MERGE (обновление со вставкой), например, ORA-30926: Unable to get a stable set of rows for MERGE operation - невозможно получить устойчивый набор строк для операции MERGE. Когда возникает ошибка, строка, вызвавшая ее, протоколируется в таблице "некорректных записей" наряду с номером ошибки, текстом сообщения об ошибке, типом операции (INSERT, UPDATE или DELETE), а также с идентификатором этой строки ROWID (для операций UPDATE и DELETE). Этой новой функциональной возможности суждено стать моей любимой возможностью сервера Oracle Database 10 g Release 2. Выполнение масштабных операций массовой обработки данных лучше построчной обработки с точки зрения скорости и использования ресурсов, но протоколирование ошибочных строк всегда было проблемой в прошлом. С появлением этой новой возможности проблема исчезла. Точки восстановления (restore points) В сервере Oracle Database 10 g Release 2 появилась новая возможность - создание точек восстановления. В сервер Oracle Database 10 g Release 1 была введена возможность ретроспективного отката базы данных (flash back a database), но для этого вы должны были знать системный номер изменения (SCN) или время, к которому нужно откатиться. Теперь в сервере Oracle Database 10 g Release 2 вы можете создать точку восстановления: CREATE RESTORE POINT "X", затем сделать что-то потенциально опасное, возможно, попытаться провести модернизацию некоторого приложения, и если в процессе модернизации произойдет сбой, вы можете просто выполнить оператор ретроспективного отката базы данных до точки восстановления: FLASHBACK DATABASE TO RESTORE POINT "X". Вам больше не нужно перед выполнением ретроспективных операций придумывать оператор SELECT для поиска SCN или угадывать время, к которому нужно откатиться. "Прямая" поддержка языка XQuery В сервер Oracle Database 10 g Release 2 добавлена собственная реализация языка XQuery, нового стандарта консорциума W3C для XML-запросов. В эти новые средства введены две новых функции XMLQUERY и XMLTABLE. Функция XMLQUERY позволяет выполнять запросы к документам репозитория Oracle XML DB или к XML- представлениям реляционных данных, используя на SQL-клиенте язык XQuery. Функция XMLTABLE позволяет преобразовать результат выполнения Xquery-выражения в реляционные строки и столбцы, чтобы с этим результатом могли работать SQL-запросы. Подводя итоги сказанного Это был только быстрый взгляд на некоторые из новых функциональных возможностей сервера Oracle Database 10 g Release 2. Теперь, чтобы использовать все преимущества нового материала, я начинаю полное чтение документации. Ведущий данной колонки Том Кайт (Tom Kyte , thomas.kyte@oracle.com ) работает в корпорации Oracle с 1993 года. Кайт - вице-президент корпорации Oracle, возглавляющий группу Oracle Public Sector, он автор книг "Effective Oracle by Design" (издательство Oracle Press, 2003) - "Проектирование эффективных приложений Oracle" и "Expert One on One: Oracle" (издательство Apress, 2003) ( Прим. пер. Имеется русский перевод: Oracle для профессионалов. Книга 1. Архитектура и основные особенности. Книга 2. Расширение возможностей и защита. - ДиаСофт, 2003 г.).
|
|