A simple interview question

oracle: JDBC Thin Client in v$session

Заметки о том как отображаются сессии от JDBC Thin Client в v$session

Если попытаться посмотреть информацию о JDBC Thin Client в v$session, то всегда v$session.process = 1234

SELECT s.program,s.process, s.sid, s.seq#, s.event
  FROM v$session s

JDBC Thin Client

1234

4894

29653

db file sequential read

Почему так происходит, почему PID клиентского процесса в OS всегда 1234 в случае с JDBC Thin Client ?

Ответ:


How to Set V$SESSION Properties Using the JDBC Thin Driver [ID 147413.1]

Note: The JDBC driver cannot correctly retrieve the values of some V$SESSION
properties on its own. Specifically, the driver exhibits the following behavior:

 - When querying the TERMINAL field of the V$SESSION table using the JDBC
Thin driver, the value returned is "unknown".

- When querying the PROCESS field of the V$SESSION table using the JDBC
Thin driver, the value returned is "1234".

- The driver returns the process ID as "1234" by default, since obtaining
a process ID is not possible using the JDBC Thin driver.




Java developer can provide value in code (if code change is an option) using Java Properties when creating JDBC connection:
         prop.put("v$session.process", clientProcess);
         prop.put("v$session.program", programName);

oracle: кто использует TEMPORARY Tablespaces

Нужно узнать какие сессии используют временное табличное пространство в данный момент:

SELECT DISTINCT s.username, s.sid, s.serial#, s.osuser, u.TABLESPACE, u.contents, u.segtype, u.extents, u.blocks
FROM v$session s, v$sort_usage u
WHERE s.saddr=u.session_addr
ORDER BY s.username, s.osuser;

oracle: мониторинг объектов схемы

1. Посмотреть кто к каким объектам схемы обращается.

-- кто к каким объектам схемы обращается
SELECT a.object,
       a.type,
       a.sid,
       b.username,
       b.osuser,
       b.program
FROM   v$access a,
       v$session b
WHERE  a.sid   = b.sid
AND    a.owner = UPPER('arbor')
ORDER BY a.object;

Используем представление V$ACCESS.
V$ACCESS содержит информацию о блокировках, которые в данный момент наложены на объекты library cache. Это делается для того чтобы они не ушли из library cache пока они требуются для выполнения sql запроса.

2. Есть программа, нужно узнать к каким объектам она обращается.

-- основываясь на п.1, можно посмотреть информацию о том: какая конкретная программа
-- какие объекты использует
SELECT a.object,
       a.TYPE,
       a.sid,
       b.username,
       b.osuser,
       b.program
  FROM v$access a, v$session b
 WHERE     a.sid = b.sid
       AND a.owner = UPPER ('arbor')
       AND b.program LIKE 'ck_KenanPaymentCreate%'
ORDER BY a.object;

oracle: мониторинг блокировок

oracle: блокировки (locks), защёлки (latches), enqueues
Мониторинг блокировок (http://my-oracle.it-blogs.com.ua/)

Запросы для мониторинга блокировок в базе.

-- смотрим блокировки, установленные текущими транзакциями в базе,
-- которые блокируют запросы на блокировку от других сессий (where block=1)

SELECT l.SID,s.username,s.program,l.TYPE,l.LMODE,ROUND(CTIME/60) "Time(Min)",
(SELECT object_name FROM dba_objects WHERE object_id=lo.object_id) obj,
DECODE(lo.locked_mode,
   0, 'None',           /* Mon Lock equivalent */
   1, 'Null',           /* N */
   2, 'Row-S (SS)',     /* L */
   3, 'Row-X (SX)',     /* R */
   4, 'Share',          /* S */
   5, 'S/Row-X (SSX)',  /* C */
   6, 'Exclusive',      /* X */
   TO_CHAR(lo.locked_mode)) mode_held
FROM V$LOCK l, v$locked_object lo, v$session s
WHERE block=1
AND l.sid=lo.session_id AND l.sid=s.sid;

-- смотрим активные сессии, которые чего то ждут, и чего они собственно ждут

SELECT s.program,s.username,s.osuser,s.machine,sw.* FROM v$session_wait sw,v$session s
WHERE sw.sid=s.sid
AND sw.event<>'rdbms ipc message' AND sw.event NOT LIKE 'SQL*Net%'
ORDER BY sw.event ASC;

-- смотрим блокировки, установленные текущими транзакциями в базе,
-- кто и на что и какой тип блокировки установил

SELECT  oracle_username, session_id,s.program,object_name,DECODE(a.locked_mode,
   0, 'None',           /* Mon Lock equivalent */
   1, 'Null',           /* N */
   2, 'Row-S (SS)',     /* L */
   3, 'Row-X (SX)',     /* R */
   4, 'Share',          /* S */
   5, 'S/Row-X (SSX)',  /* C */
   6, 'Exclusive',      /* X */
   TO_CHAR(a.locked_mode)) mode_held
FROM V$LOCKED_OBJECT a,DBA_OBJECTS b,v$session s WHERE a.object_id = b.object_id
AND a.session_id=s.sid;

oracle: Мониторинг отката транзакции

Если по какой то причине сделали rollback транзакции, то интересно как долго он будет выполнятся. Оценить это можно сделав запросы к v$transaction.

В этом представлении есть два поля USED_UREC и USED_UBLK.
USED_UREC - Number of undo records used
USED_UBLK - Number of undo blocks used

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

Запросы для мониторинга:

select * from v$transaction;

-- конкрето поля USED_UREC и USED_UBLK
SELECT a.sid, a.username, b.xidusn, b.used_urec, b.used_ublk
  FROM v$session a, v$transaction b
  WHERE a.saddr = b.ses_addr;

oracle: сессии (V$SESSION, V$SESS_IO, V$ACCESS, V$SESSTAT)

--
-- SQL-команды, выполняемые в каждом сеансе
-- v$session, v$sqltext
--

select a.sid,

       a.username,

       s.sql_text

from v$session a, v$sqltext s

where a.sql_hash_value = s.hash_value

   and a.sql_address    = s.address

   and a.username is not null

order by a.username, a.sid, s.piece;

oracle: объекты закреплённые/незакреплённые в library cache

V$DB_OBJECT_CACHE

select * from v$db_object_cache;

kept = "YES" - объект закреплён в памяти
kept = "NO"  - объект не закреплён в памяти

oracle: % попадания в library cache

% попадания SQL запросов и PL/SQL в library cache:

select * from v$librarycache;

pinhitratio - % попаданий при выполнении (95%)
reload hit ratio - % попаданий при загрузке (99%). Т.е. число повторных загрузок не должно превышать 1%. Под повторной загрузкой подразумевается ситуация, когда команда уже была разобрана ранее, но не удержалась в памяти из-за загрузки других команд. Тогда тело команды выкидывается, заголовок остаётся. То же самое происходит, когда меняется план выполнения команды.

oracle: % попадания в кэш словаря

Чтобы узнать насколько часто запросы к данным словаря удовлетворяются из кэша, нужно использовать представление V$ROWCACHE .

select * from v$rowcache;
select sum(gets), sum(getmisses), (1 - (sum(getmisses)/ (sum(gets) + sum(getmisses))))*100 hit_rate from v$rowcache;

oracle: использование V$DB_CACHE_ADVICE

Прогнозирует как изменение размера кэша данных скажется на проценте попадания в кэш:

select * from v$db_cache_advice;

Чтобы это работало параметр DB_CACHE_ADVICE дожнен иметь значение ON.

oracle: посмотреть лицензионные ограничения базы данных

select * from v$license;

если 0 - ограничений нет

oracle: посмотреть версию базы данных

select * from v$version;

BANNER
================================================
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
PL/SQL Release 9.2.0.5.0 - Production
CORE    9.2.0.6.0    Production
TNS for IBM/AIX RISC System/6000: Version 9.2.0.5.0 - Production
NLSRTL Version 9.2.0.5.0 - Production
 

oracle: посмотреть запросы, по которым строятся V$ и DBA представления

Список представлений:

select * from dict;
select * from v$fixed_table;

Текст запроса, по которым строятся представления:

select * from dba_views;

select * from v$fixed_view_definition;

oracle: список установленных компонентов

Если надо узнать поддерживает ли инстанс партицирование, RAC и другие фичи,
делаем селект:

select * from v$option;

oracle: Посмотреть статистику текущей сессии

-- Посмотреть статистику текущей сессии
-- v$statname, v$mystat

select a.statistic#, a.name, a.class,b.value
from v$statname a, v$mystat b
where a.statistic# = b.statistic#;

где поле class:
    1 - User
    2 - Redo
    4 - Enqueue
    8 - Cache
    16 - OS
    32 - Real Application Clusters
    64 - SQL
    128 - Debug

oracle: блоки каких объектов в buffer_cache

Недокументированная таблица X$BH содержит информацию о заголовках буферов в буферном кеше.

Посмотреть блоки каких объектов находятся в буферном кеше:

select
 s.owner owner,
 object_name objname,
 subobject_name subobjname,
 substr(object_type,1,10) objtype,
 ts.block_size / 1024 blockkb,
 buffer.blocks blocks,
 s.blocks totalblocks,
 (buffer.blocks * ts.block_size / 1024) memkb,
 (buffer.blocks/decode(s.blocks, 0, .001, s.blocks))*100 bufferpercent
from
 (select o.owner, o.object_name, o.subobject_name,
         o.object_type object_type, count(*) blocks
  from dba_objects o, v$bh bh
  where o.object_id = bh.objd and o.owner not in ('SYS','SYSTEM')
  group by o.owner, o.object_name, o.subobject_name, o.object_type) buffer,
  dba_segments s,
 dba_tablespaces ts
where s.tablespace_name = ts.tablespace_name
  and s.owner = buffer.owner
  and s.segment_name = buffer.object_name
  and s.SEGMENT_TYPE = buffer.object_type
  and (s.PARTITION_NAME = buffer.subobject_name or buffer.subobject_name is null)
order by memkb desc;

oracle: статистики redo

Статистики REDO из представлений V$SESSTAT and V$SYSSTAT

redo log space requests 
Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch. Log files that are small in relation to the size of the SGA or the commit rate of the work load can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing. Also examine the log file space and log file space switch wait events in V$SESSION_WAIT