Процессы Oracle

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



Процесс — это по существу соединение или поток операционной системы, который выполняет определенную задачу. Процессы Oracle, с которыми вы познакомитесь в настоящей статье, являются непрерывными, в том смысле, что они запускаются при запуске экземпляра и остаются активными на все время жизни экземпляра. Таким образом, они служат “руками” Oracle, запущенными в ресурсы операционной системы. Процесс (process) на системе UNIX является аналогом потока (thread) в системе Windows.

Процессы Oracle делятся на два основных типа — для эффективности и для отделения клиентских процессов от задач сервера базы данных.

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

 

Взаимодействие между пользователем и процессами Oracle

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

Более подробно вы познакомитесь с двумя типами процессов Oracle — серверными и фоновыми в ниже.

 

Серверный процесс Oracle

Когда вы запускаете инструмент Oracle, такой как OEM Database Control, или интерфейс SQL*Plus, то делаете это через пользовательский процесс. Сеанс Oracle — это специфическое соединение пользователя с экземпляром Oracle через пользовательский процесс Oracle. Длительность сеанса простирается от момента подключения к базе данных с указанием комбинации имени и пароля пользователя до момента выхода (log out).

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

Серверный процесс создается для обслуживания пользовательского процесса и используется этим пользовательским процессом для взаимодействия с сервером Oracle. Так,например, когда пользователь посылает запрос на выборку данных, серверный процесс,созданный для обслуживания пользовательского приложения, проверяет синтаксис кода и выполняет код SQL. Затем он читает данные из файлов в блоки памяти. (Если другой пользователь захочет прочесть те же данные, то его пользовательский процесс прочтет их не с диска, а из памяти Oracle, где данные обычно находятся некоторое время.) И,наконец, серверный процесс вернет запрошенные данные пользовательскому процессу.

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

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

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

Резидентный пулинг соединений базы данных (database resident connection pooling — DRCP). Этот метод соединения, представленный в выпуске Oracle Database 11g, подходит приложениям, которые должны поддерживать постоянное подключение к базе данных, что повышает требования к серверным ресурсам.DRCP позволяет устанавливать пул выделенных соединений, совместно используемый приложениями и процессами. Когда клиент запрашивает соединение с базой данных, брокер соединений вместо выделенного сервера подключает клиента к базе данных. Брокер соединений отвечает за управление клиентскими соединениями, выделяя сервер из пула выделенных серверов. Брокер соединений связывает клиентское соединение с выделенным сервером, и как только клиентский запрос выполнен, выделенный сервер возвращается в пул доступных серверов.

Важнейшие методы соединений с Oracle, включая новый метод DRCP, объясняются в моих следующих заметках блога.

 

Фоновые процессы Oracle

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

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

Фоновый процесс Функция
Писатель базы данных(database writer — DBWn)  Пишет модифицированные данные из буферного кэша на диск (в файлы данных)
Писатель журнала(log writer — LGWR)  Пишет содержимое буфера журнала повторного выполнения в файлы онлайнового журнала повторного выполнения
Процесс контрольных точек(checkpoint — CKPT)  Обновляет заголовки всех файлов данных, фиксируя детали контрольных точек
Монитор процессов(process monitor — PMON)  Выполняет очистку после остановленных и сбойных процессов
Системный монитор(system monitor — SMON)  Выполняет восстановление после сбоев и объединение экстентов
Архиватор(archiver — ARCn)  Архивирует заполненные файлы журналов повторного выполнения
Монитор управляемости(manageability monitor — MMON)  Выполняет задачи, связанные с управлением базой данных
Монитор управляемости облегченный(manageability monitor light — MMNL)  Выполняет такие задачи, как фиксация хронологии и метрик сеанса
Диспетчер памяти (memory manager — MMAN) Координирует размеры компонентов SGA
Процесс координации очереди заданий(job queue coordination process — CJQO)  Координирует очереди запланированных заданий

В следующих разделах мы кратко обсудим основные фоновые процессы Oracle.

 

Писатель базы данных (процесс DBWn)

Oracle не модифицирует данные прямо на диске. Все модификации данных происходят в памяти Oracle. Процесс писателя базы данных затем отвечает за запись “грязных” (модифицированных) данных из областей памяти, называемых буферами базы данных,в файлы данных на диске.

Работа процесса DBWn состоит в том, чтобы отслеживать использование буферного кэша базы данных, и если свободное место в буфере сокращается, то этот процесс освобождает память, записывая некоторые данные из буферов в дисковые файлы. Процесс писателя базы данных применяет алгоритм самого последнего использованного (least recently used — LRU) (либо его модифицированную версию), который сохраняет данные в буферах памяти в зависимости от периода времени, прошедшего с момента последнего запроса этих данных. Если часть данных запрашивалась недавно, более вероятно,что она будет сохранена в буферах памяти.

Процесс писателя базы данных пишет “грязные” буферы на диск при следующих условиях.

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

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


Для очень больших баз данных или баз, выполняющих интенсивные операции,единственного процесса-писателя может оказаться недостаточно для выполнения всего объема записи в файлы данных. На этот случай в Oracle предусмотрено применение нескольких процессов-писателей, распределяющих между собой нагрузку по модификации данных на диске. Вы можете использовать до 20 процессов-писателей (от DBW0 до DBW9 и от DBWa до DBWj). Oracle рекомендует использовать несколько процессов-писателей только в том случае, если на сервере установлено несколько процессоров.

Вы можете специфицировать дополнительный процесс-писатель базы данных, используя параметр инициализации DB_WRITER_PROCESSES в конфигурационном файле Oracle SPFILE. Если вы не указываете этот параметр, Oracle выделяет количество процессов-писателей в зависимости от количества процессоров и процессорных групп на вашем сервере. Например, на 32-процессорном сервере HP-UX автора существует по умолчанию четыре писателя базы данных (по одному на каждые 8 процессоров), а на другом — 16-процессорном сервере — по умолчанию всего два писателя базы данных.

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

 

Писатель журналов (процесс LGWR)

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

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

Писатель журналов пишет элементы буфера журнала повторного выполнения при наступлении следующих условий.

  • Истечение каждых 3 секунд.
  • Когда буфер журнала повторного выполнения заполнен на треть.
  • Когда писатель базы данных сигнализирует о необходимости записи журнала повторного выполнения на диск (т.е. в файлы журналов повторного выполнения на диске) перед тем, как файлы данных на диске могут быть модифицированы. В процессе записи “грязных” буферов из буферного кэша на диски, если писатель базы данных обнаружит, что определенная информация повторного выполнения не была записана в файлы журналов повторного выполнения, он сигнализирует писателю журнала, чтобы тот сначала записал эту информацию, чтобы потом он мог записать на диск свою собственную информацию.
  • В дополнение, как упоминалось ранее, сразу после фиксации транзакции писатель журналов пишет запись о фиксации в журнал повторного выполнения. Файлы журналов повторного выполнения, как вам уже известно, жизненно важны для восстановления баз данных Oracle с потерянных или поврежденных дисков.

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

При выдаче оператора фиксации (commit), чтобы сделать изменения данных постоянными, писатель журнала сначала помещает запись о фиксации в буфер журнала повторного выполнения и немедленно вносит ее в журнал повторного выполнения на ряду с информацией, касающейся текущей транзакции. Занесение в журнал записи о фиксации — важнейшее событие, которое отмечает фиксацию транзакции. Всякая зафиксированная транзакция получает номер системного изменения, который вносится писателем журнала в журнал повторного выполнения. База данных использует SCN-номера при восстановлении данных. База данных откладывает изменения блоков данных на диске до более подходящего времени и возвращает код успеха, свидетельствующий об успешной фиксации транзакции, хотя буферы с измененными данными еще не были скопированы в файлы данных на диске. Такая техника подтверждения успеха транзакции с опережением действительной записи измененных блоков данных на диск называется механизмом быстрой фиксации.

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

Контрольная точка

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

Каждая запись контрольной точки состоит из списка всех активных транзакций и адреса последней записи журнала для этих транзакций. Процесс создания контрольной точки включает следующие шаги.

  1. Сброс содержимого буферов журнала повторного выполнения в файлы журнала повторного выполнения.
  2. Внесение записи контрольной точки в файл журнала повторного выполнения.
  3. Сброс содержимого буферного кэша базы данных на диск.
  4. Обновление заголовков файла данных и управляющих файлов после завершения контрольной точки.

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

 

Монитор процессов (PMON)

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

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

 

Системный монитор (SMON)

Процесс системного монитора (SMON), как следует из его названия, выполняет задачи мониторинга системы для экземпляра Oracle, например, такие, как перечисленные ниже.

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

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

 

Архиватор (ARCn)

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

База данных делает доступной для архивации группу журналов повторного выполнения сразу по завершении переключения журналов. Задача процесса ARCn состоит в том, чтобы скопировать один из заполненных членов группы журналов повторного выполнения в архивный файл журнала повторного выполнения. Таким образом, если вы выполняете мультиплексирование журнала повторного выполнения, и группа 1 содержит члены a_log1 и b_log1, фоновый процесс архиватора скопирует любой из двух членов. Этот архивный файл журнала повторного выполнения включит в себя записи повторного выполнения из члена группы журналов.

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

Если в базе данных проводится огромное число изменений, и журналы заполняются очень быстро, вы можете использовать несколько процессов архиватора — вплоть до 30 (от ARC0 до ARCn). Параметр LOG_ARCHIVE_MAX_PROCESSES в инициализационном файле определяет количество процессов архивации, которое Oracle запустит изначально.Если процесс записи журналов пишет их быстрее, чем единственный процесс архивации по умолчанию может их архивировать, то процесс LGWR автоматически запускает новый процесс ARCn, тем самым увеличивая их количество свыше 2 по умолчанию.Поскольку база данных автоматически запускает дополнительные процессы, чтобы успевать сохранять генерируемые журналы повторного выполнения, вам на самом деле незачем устанавливать параметр LOG_ARCHIVE_MAX_PROCESSES. Поскольку это динамический параметр, его можно изменять в процессе работы базы данных, как показано ниже: 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=8; 

Совет. Если вы не знаете, какие новые фоновые процессы работают в базе данных, просто просмотрите список процессов, используя в системах UNIX и Linux команду ps –eaf | grep ora.Для каждого активного процесса будет показано имя самого процесса и имя базы данных. Например, процесс-писатель журналов будет показан как ora_lgwr_pasprod, где pasprod — имя базы данных. Получить полный список фоновых процессов (как работающих,так и не работающих) можно, запросив представление V$BGPROCESS.


 

Процессы, относящиеся к ASM

Несколько фоновых процессов появляются только в том случае, если используется система автоматического управления хранением (Automatic Storage Management - ASM). Ниже представлен список процессов, связанных с ASM.

  • Процесс мастера балансировки (rebalance master — RBAL) координирует балансировку дисковой активности при использовании системы хранилища на основе ASM.
  • Процессы балансировки ASM (ARBn) выполняют балансировку дисковой активности в экземпляре ASM.
  • Фоновый процесс ASM (ASMB) присутствует во всех базах данных Oracle, использующих систему хранения ASM. Процесс ASMB взаимодействует с экземпляром ASM, подключаясь к экземпляру ASM как процесс переднего плана.

На заметку! Процессы RBAL и ARBn используются только в случае применения системы Automatic Storage Management от Oracle. Когда вы используете ASM, то должны создать экземпляр ASM,и этот экземпляр применяет эти процессы для выполнения управления дисковым хранилищем.Процесс ASMB служит посредником между вашей базой данных (когда используется основанное на ASM дисковое хранилище) и экземпляром ASM. 


 

Прочие фоновые процессы

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

Ниже кратко описаны наиболее важные из них.

  • Монитор управляемости (manageability monitor) собирает несколько типов статистики, помогающей базе данных управлять собой, таких, например, как информация снимков AWR, являющаяся основой диагностических возможностей базы данных. В дополнение MMON подает сигнал тревоги, когда показатели базы данных пересекают свои пороговые значения.
  • Облегченный монитор управляемости (manageability monitor light), выглядящий как Manageability Monitor Process 2, когда вы опрашиваете представление V$BGPROCESS. Этот процесс сбрасывает данные из хронологии активного сеанса (Active Session History — ASH) на диск при всяком заполнении буфера. Процесс MMNL также выполняет и другие задачи, связанные с управляемостью, наподобие фиксации данных хронологии сеансов и вычисления показателей (метрик) базы данных.
  • Диспетчер памяти (memory manager) координирует размеры компонентов памяти.
  • Процесс координации очереди сообщений (job queue coordination) используется Oracle для планирования пользовательских задач. Этот процесс CJQO динамически запускает подчиненные процессы очереди задач (от J000 до J999), выполняющие пользовательские задания. Когда вы включаете средство ретроспективы баз данных, Oracle запускает процесс писателя восстановления (recovery writer — RVWR) для записи ретроспективных данных из буфера ретроспективных данных в журналы ретроспективы. В определенном смысле работа RVWR аналогична тому, что делает фоновый процесс LGWR.
  • Oracle отслеживает физическое местоположение изменений базы данных в новом файле, называемом файлом отслеживания изменений (change tracking file).Recovery Manager — утилита резервного копирования Oracle — использует файл слежения за изменениями для ускорения создания инкрементных резервных копий за счет исключения полного чтения файлов данных. Процесс писателя, следящий за изменениями (change-tracking writer — CTWR) — это новый фоновый процесс Oracle, который пишет информацию об изменениях в файл изменений.
  • Процесс восстановителя (recover — RECO) используется для координации распределенных баз данных и других специализированных процессов.

На заметку! Помимо упомянутых здесь процессов в системе могут работать и другие фоновые процессы Oracle, выполняющие специализированные задачи. Например, если вы используете Oracle Real Application Clusters, то увидите фоновый процесс под названием процесса блокировок (LOCKn), отвечающий на выполнение блокировок экземпляра.


  • Архиватор ретроспективных данных (flashback data archiver — FBDA) — процесс,отвечающий за запись изменений в таблицы, для которых включено архивирование ретроспективных данных в таблицах хронологии.
  • Фоновый процесс кэша результатов (result cache background — RCBG) — процесс,отвечающий за управление кэшем результатов.

Просмотреть все доступные фоновые процессы Oracle можно, выполнив запрос к представлению V$BGPROCESS.

 

Вас заинтересует / Intresting for you:

Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 7406 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Работа с запросами Approximate...
Работа с запросами Approximate... 1494 просмотров Андрей Васенин Mon, 29 Oct 2018, 06:40:46
Отмена сессий в Oracle (ALTER ...
Отмена сессий в Oracle (ALTER ... 10319 просмотров Stepan Ushakov Thu, 01 Nov 2018, 18:04:59
Язык SQL в Oracle
Язык SQL в Oracle 3300 просмотров Ирина Светлова Tue, 21 Nov 2017, 13:26:01
Войдите чтобы комментировать

apv аватар
apv ответил в теме #9156 02 сен 2018 15:33
Мне понравился ваш обзор процессов базы данных Oracle. Лаконично, четко и по делу! Спасибо.