прямой доступ к SGA - зачем это надо?

Во-первых, при чтении данных непосредственно из SGA, на Oracle сервер не ложится дополнительная нагрузка. Серверу не надо парсить sql, возиться с latches, buffer locks, заботиться о read consistency etc. Когда сервер уже и без того перегружен, этот плюс становится самым главным.

Во-вторых (и это вытекает из первого пункта), читать данные из SGA можно очень быстро и часто. Заведомо быстрее, чем читает сам Oracle сервер.

В третьих, к SGA можно присоединиться даже тогда, когда Oracle сервер не откликается (например, закончилось место под archive logs, превышено максимальное количество сессий).

 

Однако, есть и минусы. :)

Первый минус -- это хлопотно. К примеру, при поключении к SGA нужно знать shmid. При каждой перезагрузке Oracle instance, shmid меняется и его надо узнавать заново.

Второй минус -- read consistency при таком чтении не соблюдается. Формально, при чтении данных из, допустим, v$session мы можем получить картину сессий, не существующую ни в какой из моментов времени :) Правда, на самом деле надо отметить, что read consistency из v$ views не поддерживается и при чтении средствами Oracle. Т.е. если вы даже выполните команду 'set transaction read only', то последовательное выполнение команды 'select count(*) from v$session' будет показывать количество пользователей именно на момент выполнения команды, но не на начало транзакции!

Третий минус (и нам он кажется основным) -- как ни удивительно, но не все данные можно прочитать напрямую из SGA. В x$ таблицах есть поля, которые вычисляются Oracle'ом динамически в тот момент, когда поступает запрос на чтение этих полей.

 

В этой заметке мы рассмотрим по шагам, как прочитать из SGA информацию о пользователях в системе. Своего рода, аналог запроса

select sid,serial#,username,status from v$session;




назад далее