Программа оракал что это такое?

Файлы базы данных Oracle

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

Файлы данных (Data Files)

Все данные в базе данных Oracle сохраняются в файлах данных. Все таблицы, индексы, триггеры, последовательности, программы на PL/SQL, представления — все это находится в файлах данных. И хотя эти и другие объекты базы данных логически содержатся в табличных пространствах, в действительности они сохраняются в файлах на жестком диске компьютера.

В каждой базе данных Oracle имеется по крайней мере один файл данных (но обычно их бывает больше). Если вы создаете в Oracle таблицу и заполняете ее строками, Oracle помещает эту таблицу и строки в файл данных. Каждый файл данных может быть связан только с одной базой данных.

У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.

Данные в файлы вносятся исключительно средствами Oracle.

Следующий запрос, покажет, где находятся файлы данных.

SQL> set linesize 200;SQL> set pagesize 0;SQL> col name format a40;SQL> select file#, name, status from v$datafile; 1 /u02/oradata/ora112/system01.dbf SYSTEM 2 /u02/oradata/ora112/sysaux01.dbf ONLINE 3 /u02/oradata/ora112/undotbs01.dbf ONLINE 4 /u02/oradata/ora112/users01.dbf ONLINE 5 /u02/oradata/ora112/my_indexes01.dbf ONLINE 6 /u02/oradata/ora112/my_data01.dbf ONLINE

Оперативные файлы журналов повтора (Online Redo Log Files)

Оперативные файлы журналов повтора — предназначены для записи всех изменений, выполненных над данными базы данных Oracle. Используется для хранения на диске информации для повторного выполнения операций.

Для компьютера выполнить задачи повторно — означает выполнить ее точно так, как она выполнялась в предыдущий раз. Поэтому назначение оперативного файла журнала повтора заключается в сохранении информации об изменениях в базе данных таким, образом, чтобы позже их можно было повторить.

Поскольку файлы повтора необходимы для выполнения восстановления базы данных и являются критичными, их объединяют в группы. Запись происходит одновременно в файлы одной группы.

SQL> set linesize 200;SQL> set pagesize 0;SQL> col member format a50;SQL> select group#, member from v$logfile order by group#; 1 /u02/oradata/ora112/redo01.log 1 /u01/app/oracle/fast_recovery_area/redo01.log 2 /u01/app/oracle/fast_recovery_area/redo02.log 2 /u02/oradata/ora112/redo02.log 3 /u01/app/oracle/fast_recovery_area/redo03.log 3 /u02/oradata/ora112/redo03.log

Управляющие файлы (Control Files)

Поскольку база данных Oracle является физическим набором связанных файлов данных, то для их синхронизации и контроля требуется особые методы. Для этих целей используются управляющие файлы.

База данных Oracle может иметь один или несколько управляющих файлов. Если имеется несколько управляющих файлов, все они должны быть абсолютно идентичными. При каждом запуске базы данных Oracle читает информацию управляющего файла, а при каждом изменении размещения или добавления новых файлов данных и журналов базы данных обновляет управляющий файл.

SQL> set linesize 200;SQL> set pagesize 0;SQL> col name format a100;SQL> select name from v$controlfile; /u02/oradata/ora112/control01.ctl/u02/oradata/ora112/control03.ctl/u01/app/oracle/fast_recovery_area/ora112/control02.ctl

Файлы параметров pfile, spfie (Parameter Files)

Файлы параметров используются для конфигурирования действий Oracle предже всего при старте. Для того, чтобы запустить экземпляр базы данных, Oracle должен прочесть файл параметров и определить, какие параметры инициализации установлены для этого экземпляра. В файле параметров содержатся многочисленные параметры и их установленные значения. Oracle считывает файл параметров при запуске базы данных. Можно создать несколько файлов параметров, каждый будет соответствовать различным конфигурациям экземпляра.

• spfile — бинарный файл, который используется сервером Oracle при старте.
• pfile — текстовый файл с параметрами, будет использоваться при старте, если не будет найден spfile.

$ ls /u01/app/oracle/product/11.2/dbs/*.ora/u01/app/oracle/product/11.2/dbs/init.ora/u01/app/oracle/product/11.2/dbs/spfileora112.ora

При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.

Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.

// создания pfile из памяти (в 11 версии Oracle)

SQL> create pfile from memory;

// создать pfile из spfile

SQL> Create pfile from spfile;

Как я могу узнать, что моя база данных использует PFILE или SPFILE?:

Выполните следующий запрос, чтобы увидеть какой файл параметров был использован:

SELECT DECODE(value, NULL, 'PFILE', 'SPFILE') «Init File Type»FROM sys.v_$parameter WHERE name = 'spfile'; SQL> show parameter spfile; NAME TYPE VALUE———————————— ———— ——————————spfile string /u01/app/oracle/product/11.2/d bs/spfileora112.ora

Архивные файлы журналов повтора (Archive Log Files)

Как только оперативный файл журнала повтора (Redolog) оказывается заполнен, программное обеспечение сервера Oracle начинает запись в следующий файл. Эта операция повторяется, как следствие информация в оперативных файлах журнала (Redolog) многократно перезаписывается.

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

Архивные файлы журналов повтора жизненно важны при восстановлении. Если часть базы данных потеряна или повреждена, то для устранения повреждений обычно требуется несколько архивных журналов или туева хуча этих журналов. Файлы журналов повтора должны применяться к базе данных последовательно.

Если один из архивных файлов журналов повтора пропущен, то остальные архивные файлы журналов не могут использоваться. Храните все свои архивные файлы журналов повтора с момента выполнения последней резервной копии. Файлы журналов постепенно накапливаются и разрастаются. Иногда необходимо их удалять. Все операции с данными файлами по применению их к базе выполняются исключительно средствами базы данных.

А копировать и переносить их при желании можно как угодно. Бездумно удалять их руками не рекомендуется.

SQL> set linesize 200;SQL> set pagesize 0;SQL> col name format a100;SQL> select name from v$archived_log; …/u01/app/oracle/fast_recovery_area/ORA112/archivelog/2011_11_22/o1_mf_1_11_7dq050f1_.arc/u01/app/oracle/fast_recovery_area/ORA112/archivelog/2011_11_23/o1_mf_1_12_7dsykrjd_.arc/u01/app/oracle/fast_recovery_area/ORA112/archivelog/2011_11_24/o1_mf_1_13_7dw3fy96_.arc/u01/app/oracle/fast_recovery_area/ORA112/archivelog/2011_11_24/o1_mf_1_14_7dw3ys4f_.arc/u01/app/oracle/fast_recovery_area/ORA112/archivelog/2011_11_26/o1_mf_1_15_7f04bqyq_.arc…

Alert log и трассировочные файлы (trace file)

При работе базы данных события и ошибки регистрируются в текстовых файлах на сервере базы данных. Файл журнала предупреждений (alert log) нужен администратору базы данных для отслеживания важнейших действий с базой данных — наподобие открытия и закрытия базы данных, установления параметров загрузки базы данных и переключения оперативных журналов повтора. Также в эти файлы записываются многие ошибки базы данных для последующего расследования их причин. Любые структурные изменения базы данных также регистрируются в файле журнала предупреждений.

// в 11 версии базы данных по умолчанию:

$ ls /u01/app/oracle/diag/rdbms/rdb115/RDB115/tracealert_${SID_NAME}.log

// в 11 версии появилась XML версия. По умолчанию:

$ ls /u01/app/oracle/diag/rdbms/ora112/ora112/alertlog.xml

Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.

// в 11 версии базы данных по умолчанию трассировочные файлы хранятся

/u01/app/oracle/diag/rdbms/ora112/ora112/trace

// Следующий запрос покажет расположение трассировочных файлов.

SQL> show parameter dump_dest

Файлы паролей (Password File)

Необязательный файл, используется для защиты информации о подключениях привилегированных пользователей. Если отсутствует, то вы можете выполнять администрирование своей базы данных, только локально. Кроме того, с его помощью контролируется количество привилегированных подключений для управления в одно и то же время.

$ ls /u01/app/oracle/product/11.2/dbs/orapw*/u01/app/oracle/product/11.2/dbs/orapwora112

Источник: https://oracle-dba.ru/docs/architecture/files/

Система Oracle: структура и процессы

На рис. 1. изображена упрощенная система процессов Oracle,  которых более чем достаточно для понимания структуры базы данных. На ней изображено только самое основное (можно сказать архитектура СУБД Оракл), о чем будет рассказано в этой статье; все остальное – лишь глазурь на торте.

На рис. 1. показаны структура файлов данных базы, состоящая из двух типов файлов. Файлы с данными, хранящие «настоящие» данные, и файлы журнала повтора (redo log files, часто их называют просто файлами журнала), хранящие непрерывный поток всех изменений, производимых в файлах данных.

Рис. 1. Схема процесса Oracle, содержащая «только самое необходимое»

Файлы с данными поддерживают произвольный доступ, а для большей эффективности, каждому из них назначается размер единицы ввода/вывода – размер блока который может быть равен 2 Кбайта, 4 Кбайта, 8 Кбайт (наиболее типичное значение по умолчанию), 16 Кбайт или (на некоторых платформах) 32 Кбайта. Файлы с данными могут объединяться в логические объекты, которые называют табличными пространствами (tablespace). Табличное пространство можно рассматривать, как естественную «крупномасштабную» единицу базы данных – простые объекты данных связываются с табличными пространствами, а не с файлами данных.

Существует три основных типа табличных пространств, лежащих в основе системы Oracle Database: табличные пространства отмены (undo tablespaces), временные табличные пространства (temporary tablespaces) и «все остальное».

Временные табличные пространства появилось в версии базы данных Oracle 8, а табличные пространства отмены – в Oracle 9. До этого (начиная с версии 6, когда вообще появились табличные пространства) все табличные пространства были одинаковыми. Среди «всех остальных» имеется несколько табличных пространств, считающихся специальными (даже при том, что они интерпретируются так же, как другие табличные пространства): системное табличное пространство system и вспомогательное системное табличное пространство sysaux, которые не должны использоваться для хранения пользовательских данных.

Табличное пространство sysaux появилось в версии Oracle 10g и служит для хранения наиболее динамических и потенциально объемных данных, сгенерированных внутренними механизмами управления и обслуживания. Табличное пространство system служит для хранения словаря данных (data dictionary) – метаинформации, описывающей базу данных.

Примечание. Разумеется, существуют и другие типы файлов, но мы не будем рассматривать их в данной заметке блога.

Когда программное обеспечение выполняется под управлением ОС UNIX (и во многих других ОС), в памяти создается несколько копий одного и того же процесса, и эти копии совместно используют значительный сегмент памяти. В Windows создается единственный процесс с именем oracle, в рамках которого выполняется множество независимых потоков.

В последнем случае немного проще представить потоки, совместно использующие сегмент памяти. Формально,
файлы с данными называют базой данных (database), а комбинацию памяти и действующую программу (или программы) – экземпляром (instance).

Сегмент совместно используемой памяти (формально: системная глобальная область (System Global Area), иногда ее называют разделяемой глобальной областью (Shared Global Area), но чаще просто используют аббревиатуру SGA) хранит массу разнообразной информации.

Самыми важными хранимыми компонентами являются: кэш данных (окно в файлы с данными, хранящее копии некоторых блоков), буфер журнала (очень небольшой фрагмент памяти, используемый как циклический буфер для хранения информации, которая в скором времени будет записана в файлы журналов) и кэш библиотек (хранит информацию об инструкциях SQL и блоках PL/SQL, выполнявшихся последними).

Формально, кэш библиотек является частью разделяемого пула (shared pool), но это слишком широкий термин и, к тому же, он часто применяется для обозначения любой памяти в SGA, используемой в текущий момент.

Примечание. Существует еще несколько не менее важных компонентов системы Oracle, а именно: пул потоков данных (streams pool), Java-пул и большой пул (large pool). Но все они являются обычными областями памяти, изолированными от разделяемого пула и предназначенными для поддержки специализированных механизмов.

Все процессы, имеющие доступ к SGA, могут читать и изменять SCN. Обычно процессы читают текущее значение в начале каждого запроса или транзакции (с помощью подпрограммы kcmgss – Get Snapshot SCN), и каждый раз, когда процесс подтверждает транзакцию, он увеличивает значение SCN (с помощью
подпрограммы kcmgas – Get and Advance SCN). Значение SCN увеличивается также в других случаях, именно поэтому название «системный номер изменения» (System Change Number) лучше соответствует его сути, чем название «системный номер подтверждения транзакции» (System Commit Number).

Теперь остаются всего три процесса (точнее, три типа процессов) и один важный факт, которые вы должны знать. Важный факт: программы конечного пользователя не взаимодействуют напрямую ни с файлами данных, ни даже с разделяемой памятью.

Существует отдельный процесс, копирующий информацию из буфера журнала в файлы. Его так и называют – процесс записи в журналы (log writer, известный также как lgwr). Каждый экземпляр имеет только один процесс lgwr. Аналогично существует отдельный процесс, копирующий информацию из кэша в файлы данных.

Это – процесс записи в базу данных (database writer, известный также как dbwr).

Часто экземпляры имеют только один такой процесс, но в очень больших и высоконагруженных системах возможно (а часто и необходимо) обеспечить запуск нескольких процессов записи в базу данных, которые получат имена dbwN (где диапазон возможных значений N отличается для разных версий Oracle).

Наконец, в каждом экземпляре существует несколько копий серверных процессов. Эти процессы выполняют операции с SGA и читают файлы с данными от имени конечного пользователя. Программы конечных пользователей передают инструкции и принимают результаты через конвейер SQL*Net. Администратор базы данных (то есть, вы!) может выбирать в настройках между двумя типами серверных процессов: выделенные (dedicated) серверные процессы и разделяемые (shared, прежде их называли многопоточными (multithreaded)).

На практике чаще используются выделенные серверы, но в некоторых системах большинство легковесных задач решается с помощью разделяемых серверов, а более тяжеловесные задачи – с помощью выделенных серверов.

Что действительно нужно знать о системе Oracle?

В конечном счете все сводится к следующему:

Конечный пользователь отправляет запросы в форме инструкций SQL (или PL/SQL) серверному процессу; каждая инструкция интерпретируется и выполняется; процесс выбирает нужные данные; процессу может потребоваться изменить данные, не нарушая их целостность; экземпляр предпринимает все меры по защите базы данных от повреждений.

Вся эта работа выполняется в контексте многопользовательской системы Oracle, где множество конечных пользователей пытаются одновременно манипулировать одними и теми же данными. Вследствие этого возникает несколько важных вопросов: «Как наиболее эффективно читать данные?», «Как наиболее эффективно записывать данные?», «Как защитить базу данных?», «Как минимизировать конфликты между пользователями?» и «Когда база данных развалится, можно ли будет собрать ее обратно?».

Заключение 

В следующих статьях моего  блога мы постепенно выясним, как система Oracle решает проблемы эффективности и параллельного выполнения. Мы начнем с простых изменений данных и механизмов, которые используются в Oracle для записи и применения изменений, а затем исследуем порядок объединения изменений в транзакции. По мере знакомства с этими механизмами, мы также узнаем, как они решают проблемы конкурентного доступа, и немного коснемся некоторых проблем, возникающих из-за отсутствия временных ограничений на выполнение операций в Oracle.

Затем последует предварительное обсуждение типичных для Oracle структур в памяти, и механизмов защиты разделяемой памяти от опасных параллельных изменений. Опираясь на эту информацию, мы перейдем к исследованию механизмов поиска данных в памяти и чтения данных из дисковых файлов в память.

После этого мы сможем обсудить другие механизмы передачи данных – записи из памяти в файлы – и параллельно узнаем, как Oracle отслеживает данные в структурах памяти. Уделив значительную часть времени обработке данных, мы затем посмотрим, как Oracle обрабатывает код запросов (SQL) и узнаем, насколько механизмы обработки кода похожи на механизмы обработки данных, даже при том, что код запросов не имеет ничего общего с данными.

Источник: https://oracle-patches.com/oracle/prof/3132-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0-oracle-%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0-%D0%B8-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B

Печать на оракале: технология, способы и особенности печати Oracal

Сегодня печать наклеек приобрела большую популярность. Это связано преимущественно с привлекательным внешним видом таких изделий и простотой в использовании. Ведь для того, чтобы разместить полиграфическую продукцию данного типа, нужно потратить не более пары минут. Современные производители предлагают широкий ассортимент самоклеящихся пленок, которые отличаются между собой стоимостью и функциональными показателями (износостойкость, долговечность и т.д.). Однако наиболее распространенной считается печать на оракале – пленке с широким ассортиментом и отличными показателями качества.

Что такое оракал?

Изначально оракал являлся продукцией немецкой фирмы Orafol, однако уже давно название изделия стало именем нарицательным. Сегодня под этим словом подразумевается любая самоклеящаяся пленка, которая изготовлена из поливинилхлорида. Она чаще всего используется для оформления интерьеров дома или магазина, а также для рекламных вывесок, маленьких автомобильных стикеров и т.д.

Печать на пленке оракал осуществляется несколькими способами:

• цифровая печать;
• широкоформатная печать.

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

Качество широкоформатной печати может быть самым разнообразным. Различным типографиям удобно измерять данный коэффициент в dpi – количестве точек на один дюйм. При таком раскладе вы можете заказать печать на пленке как маленького, так и крупного формата. Все пленки оракал делятся между собой в зависимости от таких критериев:

• поверхность: глянцевая или матовая,
• толщина изделия,
• уровень адгезии,
• срок эксплуатации наклейки,
• цвет основы наклейки (прозрачный или молочный),
• способность пропускать цвет и т.д.

Преимущества материала

Если вы решили заказать самоклеящуюся рекламную полиграфию и рассматриваете все варианты, в число которых входит и печать на пленке оракал, то следует разобраться с преимуществом данной полиграфической продукции:

1. Износостойкость. Оракал отличается способностью выдерживать любой температурный режим. Он может долгое время находится на сильном морозе или под дождем. Кроме того, в отличии от многих других видов полиграфической продукции, подобная пленка имеет специальный слой, который защищает ее от ультрафиолетовых лучей. Благодаря этому изделие не меняет свой цвет, находясь под солнечными лучами.
2. Длительный срок эксплуатации. Как следствие предыдущего пункта. Из-за того, что печать на пленке оракал является устойчивой к различным повреждениям, она является долговечной.
3. Широкий ассортимент. Современные типографические центры предлагают вашему вниманию широкий ассортимент наклеек, изготовленных на оракале. Вы можете выбрать не только любой цвет, но также подобрать размер и форму будущего изделия. Пленка также допускает широкоформатную печать, что дает возможность получить максимально крупные баннеры.
4. Простота в использовании. Самоклеящаяся пленка оракал – просто находка для тех, кто хочет разместить большой баннер или вывеску за несколько минут. Она довольно легко клеится и требует разве что терпения и выдержки. Если размер изделия позволяет, то осуществить его монтаж можно даже одному человеку. Кроме того, демонтаж такой пленки – также легкий и быстрый процесс.
5. Широкий спектр применений. Оракал используется не только для печати рекламной полиграфии. Его особенности обуславливают применение подобной пленки в самых разных ситуациях, о которых ми и поговорим ниже. 
6. Доступная стоимость. Несмотря на высокое качество печати на пленке оракал, цена услуги может порадовать любого заказчика.
7. Влагоустойчивость, которая позволяет легко ухаживать за такими наклейками. При необходимости их можно просто протереть влажной тряпкой.

Применение печати на оракале

Печать на пленке оракал стала популярной сравнительно недавно. Однако в настоящее время многие владельцы крупного и малого бизнеса используют данную полиграфическую продукцию в качестве рекламы своего бренда. Хотя это далеко не единственный вариант, где может быть использовано это изделие. Благодаря технологии изготовления и особенностям таких наклеек, они применяются при:

1. Оформлении витрин магазинов. Такой вариант позволяет быстро и качественно разместить на витрине необходимый баннер. На нем будет располагаться информация об акциях/скидках/поступлении нового товара и т.д. Если печать на пленке правильно оформить, то она отлично впишется в дизайн интерьера помещения и только увеличит узнаваемость и имидж компании. 
2. Реклама на транспорте. Довольно распространенное явление в последнее время. Благодаря высокой степени износостойкости оракал как можно дольше сохраняет первоначальный внешний вид даже при передвижении транспорта во время осадков.
3. Оформление стендов и баннеров. Снова-таки, печать на пленке оракал предпочтительна в данном случае из-за высокой износостойкости продукции и способности ее выдержать любой температурный режим.
4. Оформление интерьера. В последние несколько лет широкое распространение получила интерьерная печать на пленке. Такие наклейки можно использовать в качестве декора дома, квартиры или офисного помещения.
5. Разнообразные стикеры. Небольшие наклейки, которые используют в качестве декора ноутбуков и телефонов сегодня можно встретить у многих. Также оракал используется для того, чтобы осуществить печать на пленке для авто. Такая продукция прослужит довольно долго и украсит автомобиль.
6. Оформление упаковок для всех видов товаров. Если разместить на таких наклейках название или логотип компании, получится не только практичное изделие для хранения и транспортировки товаров, но и эффективная рекламная полиграфия.

Технология печати на оракале

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

Для получения качественных стикеров или баннеров следует выполнить несколько этапов:

1. Составление дизайна будущей продукции. Если вы не можете сделать это самостоятельно, воспользуйтесь услугами профессионалов. Помните, что тем более качественно будет оформлен дизайн наклейки, тем большую эффективность она будет иметь.
2. Обсуждение с полиграфическим центром всех деталей относительно заказа. Здесь желательно обсудить не только сроки изготовления, но и размер, а также форму готовой продукции. Обратите внимание, что полиграфический сервис должен использовать современное оборудование. В противном случае результат может получиться менее качественным.
3. Подготовка к печати. Для этого чаще всего плёнку обрабатывают специальным бесцветным составом. Благодаря нему краска будет ложиться наиболее равномерно и плотно.
4. Нанесение необходимого текста и иллюстрационного материала при помощи специальной печатной машины. Современные технологии позволяют осуществить печать на пленке оракал максимально быстро. Это объясняется еще и тем, что, чем дольше будет происходить печать, тем больше вероятность того, что клей на пленке расплавится и потеряет свои свойства.
5. Постпечатная обработка. Сюда относятся ламинирование или покрытие специальным лаком.

Большое количество преимуществ пленки оракал говорит само за себя. Именно поэтому многие люди, даже не задумываясь, выбирают этот вариант печати рекламы, интерьерных наклеек, стикеров и т.д. Главное – найти полиграфический сервис, который будет гарантировать вам высокое качество работы. При тщательном выборе и правильном оформлении вы получите стильное и износостойкое изделие, которое прослужит вам как можно дольше.

Источник: https://forwardprint.com.ua/news/pechat-na-orakale-texnologiya-sposoby-i-osobennosti-pechati

Бд oracle для программиста

Нужно ли программисту прикладных приложений понимать как работает БД? Том Кайт, признанный специалист Oracle, автор знаменитой колонки asktom, в своей книге «Oracle для профессионалов. Архитектура и основные особенности.» настаивает, что это просто необходимо. Даже если в вашей команде есть грамотный администратор, знание того, как работает СУБД Oracle поможет вам лучше понимать друг друга и эффективней взаимодействовать, не говоря уже о случае, когда такого специалиста у вас нет.

В данном топике я упомяну об основных вещах, понимание которых позволит грамотно работать с БД Oracle и использовать некоторые её особенности с большой отдачей для вашего приложения. Если же вы уже прочитали вышеупомянутую книгу Тома Кайта, то можете просто исползовать эту статью в качестве памятки. Одно замечание — книжку я читал давно, и тогда еще последней версией БД Oracle была 9i, курсы по администрированию я тоже проходил по девятке, так что, если в десятке и выше что-то поменялось и добавилось, то не обессудьте.

Хотя я пишу о довольно фундаментальных вещах, которые вряд ли сильно поменяись.

Когда вы меняете данные в БД, то ваши изменения сначала идут в кэш, а потом асинхронно в нескольких потоках (число можно сконфигурировать) пишутся на диск. Синхронно же пишется специальных лог (оперативный журнальный файл), чтобы была возможность восстановить данные после сбоя, если они еще не успели с кэша сброситься на диск.

Данный подход позволяет выиграть в скорости, так как в этом случае на диск все пишется последовательно в один файл, причем можно настроить так, чтобы писалось параллельно на два или больше дисков, тем самым увеличивая надежность защиты от потери изменений. Описанных файлов должно быть несколько, и они используются по кругу: как только все данные защищенные одним из лог файлов были записаны фоновым процессом в блоки данных на диск, то данный лог файл может быть переиспользован.

Таким образом в какой-то мере это позволяет еще и сэкономить, имея ультрабыстрые диски небольшого размера только для небольших журнальных файлов используемых по кругу. Обычно я рассказываю об этом, когда мне предлагают что-то сохранять просто в файл на диске, так как это будет «быстрее» за счет того, что мы будет писать все данные последовательно и головке жесткого диска не надо будет бегать и искать рэндомные блоки.

Я все же настаиваю, что мы тут ничего не выиграем, так как будем писать на медленный диск, который скоро всего активно используется множеством других процессов для записи огромного количества различных логов, а Oracle синхронно тоже пишет у себя на диск только последовательно, как я описал выше.

Механизм восстановления данных

В СУБД Oracle можно включить архивацию вышеописанных оперативных журнальных файлов, и все изменения будут архивироваться. Таким образом при потере любого диска с блоками данных мы можем восстановить их на любой момент времени, включая момент прямо перед падением, накатив на последние архивные журнальные файлы текущий оперативный журнал.

Stand by копия

Вышеупомянутые архивные файлы можно отправлять по сети и на лету применять к копии БД. Таким образом у вас всегда под рукой будет горячая копия с минимальным запаздыванием данных. В некоторых приложениях, где нет необходимости показывать данные с точностью до последнего момента, можно настроить такую БД только на чтение и разгрузить основной экземпляр БД, причем таких экземпляров на чтение может быть несколько.

Подвисание некоторых запросов на запись

При зависании некоторых ваших запросов в произвольный момент времени стоит заглянуть в alert.log на предмет наличия incomplete checkpoint. Это говорит о том, что ваши оперативные журнальные файлы слишком большие или их слишком мало, таким образом, защищаемые ими данные не успевают сбрасываться из кэша на диск, а СУБД заполнила уже все доступные оперативные журнальные файлы и хочет использовать их по кругу повторно, чего делать ни в коем случае нельзя, вот и появляется пауза. Хотя если ваше приложение работает на java, то в первую очередь я бы загляну на наличия Full GC в логах.

Неблокирующее чтение и сегмент отката

Одной из наиболее замечательных особенностей СУБД Oracle является неблокирующее чтение, которое достигается за счет сегмента отката. Запросы к Oracle на чтение никогда не блокируются, так как данные почти всегда могут быть прочитаны из сегмента отката.

Сегмент отката дает еще одну плюшку: из него можно попытаться считать немного устаревшие данные для какой-нибудь таблицы, которые были в ней на определенный момент. Называется данная фича — flashback.

Однако иногда сегмент отката может подложить свинью: если у вас есть большой job для bulk удаления данных (удаление генерирует всех больше данных в сегменте отката), то вы можете получить ORA-01555: snapshot too old. Главное что в этом случае надо помнить — это то, что не надо переписывать ваш job, чтобы он коммитил через каждые N операций, а нужно использовать отдельный специально созданный сегмент отката для таких операций.

Уровни изоляции транзакций

В Oracle вообще нет уровня изоляции READ_UNCOMMITED. Дело в том, что в других базах данных он используется для достижения максимального параллелизма путем удаления блокировок чтения. Но в Oracle чтение и так всегда выполняется без блокировок, таким образом мы уже имеем все преимущества, которые может дать этот уровень, не вводя никаких дополнительных ограничений.

Вообще, в Oracle явно доступно всего два уровня изоляции: по умолчанию используется READ_COMMITTED, но при желании вы можете установить SERIALIZABLE.

Однако на уровне операторов (SELECT, UPDATE и т.д.) у вас по умолчанию уже есть REPEATABLE_READ, т.е. в рамках одного оператора вы всегда получаете согласованное чтение, что достигается конечно же за счет сегмента отката. Мне всегда очень нравился пример приводимый Томом Кайтом для описания того, что это дает.

Допустим у вас есть очень большая таблица со счетами и вы выполняете SELECT на получение суммы. В Oracle, в отличие от многих других БД, даже если в середине вашего запроса другая транзакция переведет некоторую суммы с первого счета на последний, вы в итоге все равно получите данные актуальные на начало вашего запроса, так как дойдя до последний строчки ваш SELECT увидит, что строчка была изменена, пойдет в сегмент отката и прочитает данные, которые были в этой ячейке на момент начала выполнения запроса.

Во многих других базах данных, вы получите ответ в виде суммы, никогда не существующей в вашей таблице. Однако в Oracle в данном случае есть опасность получить ORA-01555: snapshot too old.

В дополнение к стандартным уровням изоляции в Oracle еще есть так называемые READ_ONLY транзакции, которые дают REPEATABLE_READ в рамках всей транзакции, а не только в рамках одного оператора. Но как следует из названия, в такой транзакции вы можете выполнять только чтение.

Позвольте Oracle кэшировать ваши данные эффективно

В Oracle все данные читаются-пишутся не прямо на диск, а через кэш. По умолчанию кэш основан на LRU алгоритме, так что если вы читаете какую-нибудь очень большую табличку по идентификатору в больших количествах, запрашивая в каждый раз новую строчку, то такие запросы могут вытеснять из кэша небольшую статическую табличку, которой бы самое милое дело постоянно находиться в кэше.

Для таких целей при создании таблицы вы можете указать специальный вид кэша, куда будут ходить запросы к вашим таблицам. Так для первой таблицы в вышеописанном примере подойдет кэш RECYCLE, который по сути не хранит никакие данные, а сразу их выбрасывает из кэша.

А для второй таблицы подойдет кэш KEEP, который позволить хранить в кэше небольшие статические таблице и запросы ко всем остальным таблицам не будут вытеснять данные статических таблиц из кэша.

Пустые строки

В оракл есть одна очень интересная особенность, от которой они теперь уже никогда не смогут избавиться. Дело в том, что если вы кладете в БД пустую строку, то она сохраниться как NULL. Таким образом при последующем чтении вы никогда не получите пустой строки, а только NULL. Имейте так же в виду, что по этой же причине пустые строки не попадают в индекс, так что если вы будете делать запросы, план выполнения которых, будет использовать индекс, то ваше пустые (вернее NULL) строки вы никогда не получите, но об этом чуть позже.

Индексы

Кроме всем известных индексов в виде B-деревьев в Oracle еще есть так называемые битовые индексы, которые показывают очень высокую производительность на запросах к таблицам в которых есть колонки с очень разреженными значениями. Особенно эффективно в этом случае будут работать запросы (по сравнению с обычными индексами) в которых присутствуют сложные комбинации OR и AND к разряженным столбцам.

Данный индекс храниться не в B-дереве, а в битовых картах, что и дает возможность быстрого выполнения описанных запросов. Вопрос в количестве уникальных значений в таблице при которых данный индекс еще будет более предпочтителен весьма сложен: это может быть как 10 уникальных значений, так и 10 000. Здесь надо создавать индекс на конкретной таблице и смотреть что получается.

Главное не пытайтесь использовать данный индекс на таблицах с большим количеством вставок и обновлений индексируемой колонки, так как такие операции будут блокировать довольно большие участки в индексируемой таблице и ваша система может встать колом или даже поймаете deadlock. Одна из вещей, которая меня всегда очень радовала в Oracle — это возможность создания индекса по функции. Т.е.

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

С другой стороны данное свойство можно очень эффективно использовать дня некоторых специфичных случаев. Например, у вас есть очень большая табличка в которой хранятся ордера, которая никогда не чистится. И существует фоновый процесс, который обязан все ордера отсылать в какую-нибудь backoffice систему. Первое решение, которое напрашивается — это завести еще одну колонку с флагом is_sent, где изначально стоит 0 и при отсылке мы будем проставлять 1. Т.е.

фоновый процесс при каждом запуске будет делать запрос к таблице с условием is_sent=0. Битовый индекс вы здесь использовать не можете, так как табличка очень активно пополняется. Обычный индекс на основе В-дерева будет занимать очень много места, так как нужно хранить ссылки на огромное количество строчек. Но если мы слегка поменяем нашу логику и в качестве пометки отсылки, и в колонку is_sent будем класть NULL вместо 1, то индекс у нас будет крошечный, так как в любой момент в нем будут храниться только не NULL значения, а их будет очень мало.

Таблицы бывают разные

Кроме обычных таблиц в oracle как и во многих других БД есть так называемые индекс-таблицы, когда данные таблицы непосредственно лежат в индекс-дереве первичного ключа. Таким образом достигается сразу две вещи: во первых для чтения данных по первичному ключу вы имеете на одно чтение меньше, во вторых данные в таблице получаются упорядоченными по первичному ключу, так что операция ORDER BY PK будет выполняться без дополнительной сортировки.

К недостаткам можно отнести тот факт, что отличить логирование в оперативные журнальные файлы данного индекса вы уже не сможете. Еще один замечательный тип таблиц — это кластерные таблицы, которые позволяют хранить данные из двух или более таблиц кластеризованные по одному значению ключа в одном блоке данных. Это может быть весьма эффективно если вы всегда используете какие-нибудь таблицы совместно.

На основе кластерных таблиц есть еще кластерные хэш-таблицы, в которых для доступа вместо B-дерева используется таблица на основе хеша кластерного ключа. Звучит, конечно, очень интересно, но, честно говоря, на практике никогда не сталкивался.

Связывание переменных

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

Если различных запросов очень много, как, например, весьма распространенный запрос по ID, то на каждый запрос буден генериться свой план, к тому же они будут вытеснять из кэша все другие планы, что может в разы увеличить время отклика вашей базы данных.

Стоит так же заметить, что не стоит этим злоупотреблять и использовать связывание для столбцов с небольшим количеством различных значений, как-то флаг is_deleted, ведь различных запросов в этом случае будет не так много, а, возможно, для более конкретного запроса СУБД удастся построить более эффективный план.

Еще пара заметок для программиста

Если у вас колонка имеет тип VARCHAR2(100), то попытка туда запихнуть строку longString.substring(0, 100) не факт, что увенчается успехом, так как ограничение 100 в определении колонки по умолчанию относится к количеству байтов, а не символов, поэтому при наличии двухбайтовых символов вы можете попасть впросак. На самом деле данное поведение можно немного сконфигурировать, подробнее можно почитать тут.

Хорошо если вы еще не пытаетесь выполнить вставку в бесконечном цикле, по принципу делать пока не получиться, ведь это «получиться» в данном случае никогда не наступит. Ну и общая рекомендация для всех типов БД: никогда не делайте update всех колонок в таблице при изменении одного поля объекта.

Кажется весьма очевидным, но как показывает практика, данный антипаттерн часто имеет место быть, поэтому я настоятельно рекомендую проверить, что ваши фреймворки делают UPDATE только действительно измененных полей.

Заключение

Я попытался описать большинство вещей, который на мой взгляд могут пригодится программисту. Так как их довольно много, то я их только обозначил, часто не вдаваясь в детали. Как конкретно сделать необходимую настройку можно всегда прочитать в упомянутой книжке Тома Кайта, найти в колонке asktom или просто нагуглить. Главное знать что гуглить, и, надеюсь, данный топик вам это подсказал.

• oracle database
• базы данных

Хабы:

Источник: https://habr.com/ru/post/120003/