oracle: users (пользователи)

1. Назначить default and temporary tablespace
alter user guppi default tablespace users
temporary tablespace temp;


2. Создать пользователя
CREATE USER user_name
  IDENTIFIED by password
  DEFAULT TABLESPACE tbs_user
  TEMPORARY TABLESPACE TEMP;

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: Индексы по внешним ключам

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

Не проиндексированный внешний ключ плох еще и в следующих случаях:

- При наличии конструкции ON DELETE CASCADE. Например, таблица ЕМР является подчиненной для таблицы DEPT. Оператор DELETE FROM DEPT WHERE DEPTNO = 10 должен вызвать каскадное удаление в таблице ЕМР. Если столбец DEPTNO в таблице ЕМР не проиндексирован, для этого придется выполнить полный просмотр таблицы ЕМР. Этот полный просмотр нежелателен; кроме того, при удалении большого количества строк из главной таблицы подчиненная будет каждый раз полностью просматриваться.

- При выполнении запроса от главной таблицы к подчиненной. Рассмотрим пример с таблицами EMP/DEPT еще раз. Очень часто таблица ЕМР запрашивается с условием по столбцу DEPTNO. Если приходится часто выполнять запрос:

select * from dept, emp
where emp.deptno = dept.deptno
and dept.dname = :X;

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

oracle: Synonym (Синонимы)

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

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

Различают два типа синонимов:

    Частный (PRIVATE)- синонимы содержаться в схеме конкретного пользователя и доступны только самому пользователю, и тем, кому он предоставил соответствующие права доступа.
    Общий (PUBLIC)- этими синонимами владеет специальная группа пользователей – PUBLIC, в результате чего эти синонимы доступны всем пользователям базы данных.

oracle: Мониторинг использования пространства индексами

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

Можно провести анализ используемого индексом пространства. 
Для этого анализируется структура индекса, с помощью SQL оператора ANALYZE INDEX … VALIDATE STRUCTURE, а затем запрашивается представление INDEX_STATS:

-- анализируем (dbms_stats не подходит)
ANALYZE INDEX object_id_idx  VALIDATE STRUCTURE;
-- смотрим
SELECT PCT_USED FROM INDEX_STATS WHERE NAME = 'имя_индекса';

Note: ANALYZE INDEX … VALIDATE STRUCTURE ставит блокировку на таблицу, по которой построен индекс.

oracle: Мониторинг использования индексов

В Oracle существует возможность мониторинга использования индексов.
Это необходимо для определения его использования. В результате можно удалить неиспользуемые индексы и сократить расход ресурсов.

-- Пример начала мониторинга индекса:
ALTER INDEX ALL_ORACLE_EVENT_NO MONITORING USAGE;

-- Для прекращения мониторинга указывается NOMONITORING, как показано ниже:
ALTER INDEX ALL_ORACLE_EVENT_NO NOMONITORING USAGE;

Кроме того, можно выполнить запрос к представлению V$OBJECT_USAGE, чтобы узнать, использовался требуемый индекс или нет. В представлении есть столбец USED, который принимает значение YES или NO, в зависимости от того, использовался ли индекс во время проведения мониторинга. Еще представлен столбец времени начала и окончания мониторинга и столбец указывающий состояние мониторинга, проводиться он на данный момент или нет, это столбец MONITORING, принимающий значение YES или NO.

Каждый раз при указании MONITORING USAGE или NOMONITORING USAGE, значения столбцов в представлении V$OBJECT_USAGE изменяются для соответствующего индекса. Информация о предыдущих запусках удаляется или сбрасывается. При указании NOMONITORING USAGE записывается время окончания.

oracle: Удаление индексов

Чтобы иметь возможность удалять индексы, индекс должен находиться в вашей схеме, или если он находить в другой схеме, то пользователю необходима системная привилегия – DROP ANY INDEX.

Основные причины удаления индекса:

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

После удаления индекса все экстенты его сегмента возвращаются в табличное пространство и становятся доступными для использования другими объектами.

В зависимости от способа создания индекса, создан ли он явно оператором CREATE INDEX, или неявно при определении ограничений целостности, зависит и способ его удаления. 

Если индекс создан через CREATE INDEX, его можно удалить, используя команду DROP INDEX, как показано в примере:

DROP INDEX EVENT_NO;

Для удаления индекса связанного с ограничением целостности необходимо удалить само ограничение или отключить его. 

Нельзя удалить индексы, связанные с ограничением целостности – UNIQUE или PRIMARY KEY.

oracle: Перестройка индексов

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

-- перестроим индекс:
ALTER INDEX EVENT_NO REBUILD;

Предложение REBUILD должно следовать непосредственно за именем индекса, предваряя все другие параметры. Его нельзя использовать вместе с DEALLOCATE UNUSED.

-- перестроим индекс в оперативном режиме:
ALTER INDEX EVENT_NO REBUILD ONLINE;

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

oracle: Создание больших индексов

При создании очень большого индекса стоит подумать о выделении временного табличного пространства большого размера для создания индекса. Далее опишем процедуру создания большого индекса:

1. Создайте временное табличное пространство, используя конструкцию CREATE TABLESPACE или CREATE TEMPORARY TABLESPACE.
2. С помощью параметра TEMPORARY TABLESPACE конструкции ALTER USER назначьте созданное табличное пространство как новое временное табличное пространство.
3. Создайте индекс с помощью CREATE INDEX.
4. Верните временное табличное пространство пользователю, выполнив ALTER USER … TEMPORARY TABLESPACE. И затем удалите ненужное табличное пространство, выполнив DROP TABLESPACE.

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

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

oracle: Создание индексов связанных с ограничением целостности

Oracle обеспечивает выполнение ограничения целостности UNIQUE или PRIMARY KEY для таблицы, создавая уникальный индекс для уникального или первичного ключа. Этот индекс создается автоматически, когда включается ограничение целостности. Когда выполняется CREATE TABLE или ALTER TABLE, для создания индекса не надо предпринимать никаких действий, но при желании можно указать предложение USING INDEX, чтобы контролировать его создание.

Чтобы включить ограничение целостности UNIQUE или PRIMARY KEY, создавая таким образом связанный с ним индекс, владелец таблицы должен иметь квоту табличного пространства, где будет храниться этот индекс, или системную привилегию UNLIMITED TABLESPACE. Индекс связанный с ограничением целостности всегда получает имя этого ограничения, если вы не укажете иное.

oracle: Уникальные и неуникальные индексы

Индексы могут быть уникальными или неуникальными.

Уникальные индексы гарантируют отсутствие двух строк в таблице с одинаковыми значениями в ключевом столбце или столбцах.

Неуникальные индексы не накладывают никаких ограничений на значения столбцов.

-- Для создания уникального индекса используется SQL оператор – CREATE UNIQUE INDEX.
CREATE UNIQUE INDEX ANIKNAME_UNIQUE_IDX ON ALL_ORACLE_ADMIN (ANIKNAME)
    TABLESPACE ALL_ORACLE_IDX;

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

oracle: Выбор столбцов для индексирования

Существует ряд рекомендаций по выбору столбцов которые стоит индексировать:

• Создавать индекс рекомендуется, если часто выбираются данные, составляющие примерно 15% от данных таблицы. Этот процент может значительно варьироваться в зависимости от относительной скорости просмотра таблицы и от степени кластеризации данных строки по отношению к ключу индекса. Чем быстрее просматривается таблица, тем ниже процент. Чем больше кластеризация данных строки, тем процент выше.
• Для повышения производительности соединений нескольких таблиц индексируйте столбцы, которые используются в соединении.
  Заметка: Для первичных и уникальных ключей индексы создаются автоматически, но при желании можно создать индексы и для внешних ключей.
• Для маленьких таблиц индексы не требуются. Если запрос занимает долгое время, то возможно количество данных в таблице значительно возросло.

oracle: Indexes and NULL

Индексы и NULL

Индексы на основе В*-дерева, кроме индекса кластера, не содержат записей для NULL, а индексы на основе битовых карт и индекс кластера - имеют.

Чтобы запрос select * from T where x is null; использовал индекс нужно, чтобы хотя бы один столбец в индексе имел ограничение NOT NULL.

Например:

-- создаём таблицу
create table t (x int, у int NOT NULL);
-- создаём индекс
create unique index t_idx on t(x,y);
-- выполняем запрос, он будет использовать индекс, т.к. у int NOT NULL 
select * from t where x is null;

oracle: Indexes and Views

Индексы и представления

Чтобы проиндексировать представление, надо просто проиндексировать базовые таблицы.

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

oracle: Index

Index (Индексы)

---

Типы индексов:
    Индексы в виде B-дерева (B-tree) – самые распространенные и используются по умолчанию
    Кластерные индексы в виде B-дерева – определяются специально для кластера
    Индексы хэш-кластера – определяются специально для хэш-кластера
    Глобальные и локальные индексы – относятся к секционированным таблицам и индексам
    Индексы с инвертированным ключом – полезны в среде Oracle Real Application Cluster
    Битовые индексы – компактные, подходят для столбцов с небольшим набором значений
    Индексы на базе функций – содержат заранее вычисленные значения функции/выражения
    Индексы домена – зависят от приложения или картриджа
 

B*Tree
Структура индекса выглядит так:

Блоки самого нижнего уровня в индексе, которые называют листовыми вершинами (leaf blocks), содержат все проиндексированные ключи и идентификаторы строк (rowid на схеме), ссылающиеся на соответствующие строки. Промежуточные блоки над листовыми вершинами называют блоками ветвления (branch blocks). Они используются для переходов по структуре. Самый верхний блок называется корневым (root block), он относится к группе branch blocks.

Индексы состоят из одного или более уровней branch blocks и одного уровня leaf blocks.

Index height - высота индекса, кол-во уровней индекса
blevel - высота кол-ва уровней branch blocks


Пример
Создадим новую пустую таблицу и создадим индекс по ней. Индекс будет состоять из одного пустого блока (он будет одновременно и root и leaf блоком). Index height = 1, blevel = 0.

Добавим строки в таблицу. По мере того как новые строки будут вставлять в таблицу, новые индексные записи будут добавляться в блок индекса, до тех пор пока блок не заполнится.
Далее Oracle выделяет два новых индексных блока и переносит все записи из начального блока (root block) в эти два новых блока, и добавляет в root block указатели(RBA - Relative Block Address) на эти два новых блока (которые теперь являются листовыми) и наименьшее проиндексированное значение из каждого из этих двух листовых блоков. RBA1 - min(value) leaf_blk_1, RBA2 - min(value) leaf_blk_2. Таким образом Oracle с этой информацией из root блока может искать нужное значение в листовых блоках.
Теперь Index height = 2, blevel = 1.

Продолжаем вставлять строки в таблицу. Два leaf блока заполняются индексами, и когда они заполнятся, Oracle добавит ещё один листовой блок, содержимое старого заполненного блока,  куда должен был бы попасть новый индекс распределяется между старым и новым листовыми блоками. Указатель на новый листовой блок помещается в root блок. Каждый раз когда листовой блок заполняется и разделяется на новый, в root записывается указатель, таким образом со временем заполнится и root блок.

Когда root блок полностью заполнится указателями, произойдёт его разделение на два branch блока, над которыми будет root блок с указателями на эти два блока. Теперь Index height = 3, blevel = 2. Как на картинке ниже:

По мере заполнения разделяются(split) листовые блоки, затем branch блоки и root блок. И так далее.

oracle: CLUSTERING FACTOR (фактор кластеризации)

CLUSTERING FACTOR - столбец в представлениях dba_indexes, user_indexes.

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

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

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

-- посмотреть и оценить фактор кластеризации (перед этим нужно собрать статистику)
exec dbms_stats.gather_table_stats(ownname=>'GUPPI', tabname=>'T', cascade=>true);

select a.index_name, b.num_rows, b.blocks, a.clustering_factor
from user_indexes a, user_tables b
where a.table_name = b.table_name and a.table_name='T';

oracle: dbms_job

Стандартные пакеты. DBMS_JOB

dbms_job может работать только с job'ами текущего пользователя!
После модификаций job'а нужно делать COMMIT !

Т.к. dbms_job оперирует с датой, то для примера получения нужных дат можно посмотреть oracle: работа с датой

Представления:
dba_jobs, all_jobs, user_jobs
dba_jobs_running, all_jobs_running, user_jobs_running

---

Enable/disable job

Отвечает ф-ция DBMS_JOB.BROKEN

Syntax

DBMS_JOB.BROKEN ( 
   job       IN  BINARY_INTEGER,
   broken    IN  BOOLEAN,
   next_date IN  DATE DEFAULT SYSDATE);

-- disable job
exec dbms_job.broken( jobno, true);
commit;

oracle: NLS

Параметры NLS можно посмотреть:

sql> show parameter nls;
select * from NLS_INSTANCE_PARAMETERS;
select * from NLS_DATABASE_PARAMETERS;
SELECT * FROM nls_session_parameters;

Если что, то меняем параметры для сессии:
alter session set nls_date_format = 'DD-MON-YYYY';
alter session set nls_date_language =  'ENGLISH';

oracle: ALTER TABLE ... MOVE

Важно. При использании ALTER TABLE ... MOVE нужно пересоздавать индексы этой таблицы.

Эта команда перемещает HWM в таблице до уровня занятых блоков. Например, в таблице HWM было на уровне 16 блоков, но потом в рез-те разных операций, занятых блоков осталось 12, но HWM остаётся на уровне 16, вот чтобы переместить HWM на уровень 12 блоков и увеличить кол-во unused blocks используется alter table move.
Но кол-во пространства, которое занимает таблица не меняется!!!

Перенести таблицу в другое табличное пространство

-- создаём табличное пространство
CREATE TABLESPACE GUPPI_TEST
DATAFILE  '/data/GUPPI/guppi_test.dbf' SIZE 1000M AUTOEXTEND OFF;

-- проверяем в каком tablespace таблица до MOVE
select * from dba_segments where segment_name='T';
select * from dba_tables where table_name='T';

-- проверяем индексы
-- check index status
select index_name,status from dba_indexes where table_name
in ('T','CDR_UNBILLED','CDR_DATA_DUC','CDR_BILLED');
-- check index status for partition
select index_name,partition_name,status from dba_ind_partitions
where partition_name like 'T%' ;


-- перемещаем таблицу в другое tablespace
alter table guppi.t move tablespace guppi_test;

-- если много таблиц, то можно сгенерить команды
select 'alter table quest.'|| table_name || ' move;' from dba_tables where owner='QUEST';


-- проверяем в каком tablespace таблица после MOVE
select * from dba_segments where segment_name='T';
select * from dba_tables where table_name='T';


-- пересоздаём индексы таблицы, если они там были
 -- в этом примере пересоздаём индексы и переносим их в другое табличное пространство
alter index guppi.object_id_idx rebuild tablespace guppi_test online;

-- если много таблиц, то можно сгенерить команды
select 'alter index quest.'|| index_name || ' rebuild online;' from dba_indexes where owner='QUEST';


-- проверяем индексы
select index_name,status from dba_indexes where table_name='T';

oracle: dbms_space

DBMS_SPACE

The DBMS_SPACE package enables you to analyze segment growth and space requirements.

Посмотреть свободное место можно DBMS_SPACE.UNUSED_SPACE и DBMS_SPACE.FREE_BLOCKS.

---

DBMS_SPACE.UNUSED_SPACE возвращает количество блоков выше HWM в сегменте,
т.е. количество блоков которые никогда не использовались ранее.

oracle: Таблицы

Типы таблиц


Heap organized tables - обычные таблицы (heap - куча), данные хранятся в неупорядоченном виде.

Index organized tables (IOT) - данные хранятся в упорядоченном виде, отсортированы по первичному ключу.

oracle: формат блока данных

Формат блока в ORACLE http://my-oracle.it-blogs.com.ua/post-43.aspx
oracle: datablock, extent, segment  

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: HAVING

HAVING - выражение из оператора SELECT, определяет условие возврата групп и используется только совместно с GROUP BY.

select duplicate_id, value

from test_duplicate

where

  value

  IN (

  select value

  from test_duplicate

  having count(*) > 1

  group by value

  )

order by value;

oracle: join

Ключевое слово join в SQL используется при построении select выражений.
Инструкция join позволяет объединить колонки из нескольких таблиц в одну. Объединение происходит временное и целостность таблиц не нарушается.

Существует три типа join-выражений:

    * inner join;
    * outer join;
    * cross join;

oracle: db file sequential read, db file scattered read

Both "db file sequential read" and "db file scattered read" events signify time waited for I/O read requests to complete. Time is reported in 100's of a second for Oracle 8i releases and below, and 1000's of a second for Oracle 9i and above. Most people confuse these events with each other as they think of how data is read from disk. Instead they should think of how data is read into the SGA buffer cache.

db file sequential read (одноблочное):
Среднее время этого ожидания = фактическому среднему времени чтения одного блока БД.

(average time to read single block , то что на уровне ОС обычно называют выборочным или случайным чтением (random read)). Типичное нормальное значение ~10 ms (10 ms – это значение по умолчанию параметра IOSEEKTIM системной статистики из sys.aux_stats$), в реальных системах может быть значительно меньше при использовании RAID controller cache + OS cache. В зависимости от соотношения (очереди на выполнение операций ввода-вывода)/(производительность системы I/O) может многократно меняться. Полезно сравнить это время ожидания со значениями, используемыми Oracle CBO для расчётов – значением параметра SREADTIM, либо IOSEEKTIM + DB_BLOCK_SIZE / IOTFRSPEED при наличии или отсутствии WORKLOAD системной статистики (sys.aux_stats$)

A sequential read operation reads data into contiguous memory (usually a single-block read with p3=1, but can be multiple blocks). Single block I/Os are usually the result of using indexes. This event is also used for rebuilding the controlfile and reading datafile headers (P2=1). In general, this event is indicative of disk contention on index reads.

db file scattered read (многоблочное):
Фактическое среднее время многоблочного чтения файлов БД (на уровне ОС называется последовательным чтением – disk sequential read). CBO использует для расчётов значения MREADTIM либо IOSEEKTIM + DB_FILE_MULTIBLOCK_READ_COUNT*DB_BLOCK_SIZE / IOTFRSPEED при наличии или отсутствии WORKLOAD системной статистики (sys.aux_stats$) 

Similar to db file sequential reads, except that the session is reading multiple data blocks and scatters them into different discontinuous buffers in the SGA. This statistic is NORMALLY indicating disk contention on full table scans. Rarely, data from full table scans could be fitted into a contiguous buffer area, these waits would then show up as sequential reads instead of scattered reads.

oracle: двухэтапная фиксация (2PC)

2PC(two phase commit) - это распределённый протокол,позволяющий фиксировать транзакцию, затрагивающую несколько баз данных

oracle: SELECT

1. select from partition
select count(*) from arbor.CDR_UNBILLED partition(CDR_UNBILLED_P_2011_05);
select count(*) from arbor.CDR_DATA partition(CDR_DATA_P_2011_05);

2.Пример селект в селекте
Лучше так не делать, т.к. селект (acct_mgr) будет выполняться для каждой строки, но вот чисто для примера можно делать такие вот селекты:

select c.customer_id, c.cust_fi rst_name|| ’ ‘||c.cust_last_name, 

    (select e.last_name from hr.employees e where e.employee_id = c.account_mgr_id) acct_mgr

from oe.customers c;

CUSTOMER_ID   CUST_NAME                                        ACCT_MGR
---------------        -----------------------------------------  --------------
            147                        Ishwarya Roberts                          Russell
            148                       Gustav Steenburgen                        Russell
...

3.