Показаны сообщения с ярлыком Oracle Database 10g. Показать все сообщения
Показаны сообщения с ярлыком Oracle Database 10g. Показать все сообщения

30 января 2009 г.

Количество ожиданий в Oracle 10g (Number of Wait Events in Oracle 10g)

Сегодня читала про ожидания в Oracle 10g и наткнулась на эту презентацию, где увидела этот график:
Я знала, что в Oracle 10g появилось очень много новых событий ожидания (wait events) но даже не думала, что настоолько много! Первым делом решила проверить это и посчитала кол-во событий ожидания в версиях 9i и 10g:

В Oracle 9.2.0.8:

SQL> select count(*) from v$event_name;

COUNT(*)
----------
406
В Oracle 10.2.0.4:
SQL> select count(*) from v$event_name;

COUNT(*)
----------
889
В 10g кол-во ожиданий увеличилось больше чем вдвое: было 406, стало 889! Здесь пишут, что события ожидания в Oracle 10g стали более "descriptive", то есть более описательными, более детальными.
Wait event names in Oracle 10g are more descriptive in the areas of latches, enqueues, and buffer busy waits.
Здесь я писала об одном из таких примеров, когда из ожидания buffer busy waits "родилось и отколось" ожидание read by other session.

21 января 2009 г.

"buffer busy waits" и "read by other session"

В Oracle 10g появились ожидания read by other session, которые являются частным и "отколовшимся" случаем ожиданий buffer busy waits. Вот что пишут в документации Oracle о них:

This event ['read by other session'] occurs when a session requests a buffer that is currently being read into the buffer cache by another session. Prior to release 10.1, waits for this event ['read by other session'] were grouped with the other reasons for waiting for buffers under the 'buffer busy wait' event.
Наталья Гусева, одна из суперских ДБА, которых я знаю, подсказала, что read by other session - это тот же buffer busy waits с reason code = 130.
Reason code = 130: Block is being read by another session, and no other suitable block image was found, so we wait until the read is completed. This may also occur after a buffer cache assumed deadlock. The kernel can't get a buffer in a certain amount of time and assumes a deadlock. Therefore it will read the CR version of the block.
Полный список и описание reason code можно почитать здесь, правда там говорится применительно версии 9i.

Ожидания read by other session возникают, когда какая-то сессия пытается прочитать блок из диска в буферный кеш, в тот момент когда другая сессия уже читает ее из диска в буферный кеш.

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

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

1 сентября 2008 г.

Flush buffer cache

Эта команда используется и в Oracle 9i и в 10g для сброса разделяемого пула.

alter system flush shared_pool
В Oracle 10g есть аналогичная команда, сбрасывающая буферный кеш:
alter system flush buffer_cache;
Только было бы замечательно уточнить, что именно происходит при сбросе буферного кеша: во-первых, записываются измененные блоки в файлы данных. Может вся хеш-таблица буферного кеша тоже чистится?

В Oracle 9i такой команды нет, но, оказывается можно сбросить буферный кеш установкой события:
alter session set events = 'immediate trace name flush_cache';

14 мая 2008 г.

Где именно находится оптимизатор
в архитектуре Oracle RDBMS?

Oracle DBA обычно не интересуются вопросом "Где именно находится оптимизатор в архитектуре Oracle RDBMS?" Некоторые из моих знакомые ДБА отнесли его к категории вопросов о смысле жизни.
Но самый популярный ответ был "в ядре Oracle".

В книге Oracle Database 10g Insider Solutions пишут тоже самое:

"The Cost Based Optimizer is at the heart of the Oracle kernel and plays a large part in the efficient execution of SQL statements in Oracle Database 10g."
Но где именно находится это ядро (kernel)? Это обычный процесс? Если да, то можно ли его увидеть в юниксе в списке процессов командой "ps"?

Отрывок из книги Тома Кайта "Oracle для профессионалов: Архитектура и основные особенности":
"При получении запроса SELECT * FROM EMP именно выделенный/разделяемый сервер Oracle будет разбирать его и помещать в разделяемый пул (или находить соответствующий запрос в разделяемом пуле). Именно этот процесс создает план выполнения запроса. Этот процесс реализует план запроса, находя необходимые данные в буферном кеше или считывая данные в буферный кеш с диска. Такие серверные процессы можно назвать "рабочими лашадками" СУБД. Часто именно они потребляют основную часть процессорного времени в системе, поскольку выполняют сортировку, суммирование, соединения - в общем, почти все."
То есть функции оптимизатора выполняются серверными процессами и их мы можем увидеть в списке процессов:
oracle@myhost$ ps -ef  grep ora  grep LOCAL  more
oracle 22790 1 0 09:13:33 ? 0:03 oracleTESTDB (LOCAL=NO)
oracle 4426 1 0 11:20:58 ? 0:02 oracleTESTDB (LOCAL=NO)
oracle 29167 1 0 11:11:32 ? 0:01 oracleTESTDB (LOCAL=NO)
oracle 12778 1 0 09:53:02 ? 0:03 oracleTESTDB (LOCAL=NO)
oracle 14349 1 0 12:26:34 ? 0:01 oracleTESTDB (LOCAL=NO)
oracle 21141 1 0 11:47:35 ? 0:01 oracleTESTDB (LOCAL=NO)
oracle 11220 1 0 09:49:18 ? 0:06 oracleTESTDB (LOCAL=NO)
oracle 16823 1 0 11:40:49 ? 0:01 oracleTESTDB (LOCAL=NO)
oracle 26760 1 0 11:57:20 ? 0:01 oracleTESTDB (LOCAL=NO)
oracle 20814 1 0 09:09:42 ? 0:01 oracleTESTDB (LOCAL=NO)
oracle 17374 1 0 12:32:28 ? 0:02 oracleTESTDB (LOCAL=NO)
oracle 8911 1 0 22:14:38 ? 0:00 oracleTESTDB (LOCAL=NO)
Если серверные процессы разбирают все запросы (выполняют все функции оптимизатора), значит ли это, что:

Код самого оптимизатора находится в каждом серверном процессе?
Или серверные процессы всего лишь вызывают эти функции из ярда Oracle?
Или ядро Oracle - это и есть серверные процессы?


Для меня этот вопрос все еще остается открытым, если у кого-то есть идеи, буду рада их услышать.

Добавлено 16 мая, 2008:
Это ответ Джонатана Льюиса на этот вопрос (публикую с его разрешения):
There is one main executable for the database in Oracle distribution, and that is called oracle (on Unix systems, but oracle.exe on Windows).
This is the program that becomes pmon, smon, dbwr, s000, and all the other background processes when the instance starts up. The bits of code run from that executable vary across the different roles played in the instance.

As such, the optimiser is just part of the code that is called only by a program which is taking on the role of a dedicated server (oracle_{SID}_nnn in unix variants) or a shared server (oracle_{SID}_Snnn).

When people talk about the 'Oracle kernel' it's actually a very informal and inaccurate expression - they are trying to give a vague impression of the most commonly used part of the code with an emphasis, perhaps, on the code segments that do a lot of synchronised work in the shared memory area. But there is no specific process that you can see that is "the" kernel.

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com

Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Перевод:

Есть один основной бинарник в дистрибутиве Oracle, который так и называется oracle (в юникс системах, и oracle.exe в Windows). Когда стартуется инстанс, эта программа превращается в фоновые процессы pmon, smon, dbwr, s000 и тд.
В зависимости от роли, которую он выполняет в составе инстанса, выполняются отдельные биты кода этого бинарника.

Оптимизатор - это всего лишь кусочек кода, который вызывается программой, выполняющей роль выделенного сервера (oracle_{SID}_nnn в юниксе) или разделяемого сервера (oracle_{SID}_Snnn).

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

Прикольно, значит код самого оптимизатора находится в каждом серверном процессе.
Спасибо всем, кто участвовал в процессе выяснения местонахождения оптимизатора в архитектуре Oracle. Отдельное спасибо Джонатану Льюису, кстати всем, кто занимается тюнингом, рекомендую почитать его книжку Основы Стоимостной Оптимизации (Cost-Based Oracle Fundamentals).

28 апреля 2008 г.

Error in upgrading 9.2.0.1 database to 10g

Today, I was trying to upgrade my 9.2.0.1 database to 10g. I installed the 10g server, and run the Pre-Upgrade Information Tool (utlu102i.sql) to analyze and prepare my 9.2.0.1 database for upgrade.

SQL> @?/rdbms/admin/utlu102i
DECLARE
*
ERROR at line 1:
ORA-20000: Version 9.2.0.1.0 not supported for upgrade to release 10.2.0
ORA-06512: at line 1523


It turned out that I should have upgraded it to at least 9.2.0.4 before installing 10g server software. Should have....
Here is the link to the upgrade documentation.

Error Creating Snapshot in AWR

When trying to run an ADDM Report in Enterprise Manager Grid Control 10g, I got the following error:

“Insufficient Data in Interval. For displaying data on this page, two historical snapshots are needed. Make sure that two snapshots are present in the target database instance. In addition modify the interval so that it is contained within two available snapshots”

I looked at Automatic Workload Repository, it wasn’t configured automatically.
Then I tried to manually create snapshot in Automatic Workload Repository:

“Are you sure you want to create a manual snapshot?
Snapshots are created automatically by the database. Creating one manually may affect the results of the automatic snapshot immediately following.”


I answered Yes, but snapshot couldn’t be created:

ORA-13516: SWRF Operation failed: SWRF Schema not initialized
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 8
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 31
ORA-06512: at line 1


Then I tried the same thing to manually create snapshot using the package:

SQL> exec dbms_workload_repository.create_snapshot();

begin dbms_workload_repository.create_snapshot(); end;

ORA-13516: SWRF Operation failed: SWRF Schema not initialized
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 8
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 31
ORA-06512: at line 1
The metalink Note:287818.1:
Error: ORA-13516 (ORA-13516)
Text: SWRF Operation failed: %s
---------------------------------------------------------------------------
Cause: The operation failed because SWRF is not available. The possible
causes are: SWRF schema not yet created; SWRF not enabled; SWRF
schema not initialized; or database not open or is running in
READONLY or STANDBY mode.
Action: check the above conditions and retry the operation.


Note:459887.1:

Cause
These errors would be caused because of wrong or invalid objects with respect to AWR

Solution
In order to resolve this issue it is recommended to drop and recreate the AWR objects , which can be done using CATNOAWR.SQL and CATAWR.SQL.

But from 10.2 onwards, the script name has changed. The catalog script for AWR Tables, used to create the Workload Repository Schema is CATAWRTB.SQL .

Dropping and recreating the AWR objects and bouncing the database:
SQL> @$ORACLE_HOME/rdbms/admin/catnoawr.sql
SQL> @$ORACLE_HOME/rdbms/admin/catawr.sql

23 апреля 2008 г.

Automatic Optimizer Statistics Collection

В Oracle 10g сбор статистики для оптимизатора выполняется автоматически запланированным джобом (scheduled job) GATHER_STATS_JOB. Данная статистика об объектах используется оптимизатором (Cost-Based Optimizer) для построения эффективных планов выполнения для запросов, тем самым значительно уменьшая время выполнения запросов.

По умолчанию, сбор статистики выполняется по ночам с 22:00 до 06:00 утра и весь день в выходные дни.
Собирается статистика только по тем объектам, у которых отсутствует статистика, или устарела.

Каким образом Oracle узнает, что статистика устарела?
Данные о кол-ве DML операциий (INSERT, DELETE, UPDATE) над объектом с момента последнего сбора статистики фиксируются в SGA, которые периодически записываются в таблицу DBA_TAB_MODIFICATIONS. База данных использует эти данные для того, чтобы определить устарела ли статистика объекта.

Из документации Oracle:

Optimizer statistics are automatically gathered with the job GATHER_STATS_JOB. This job gathers statistics on all objects in the database which have:
Missing statistics
Stale statistics

This job is created automatically at database creation time and is managed by the Scheduler. This Scheduler runs this job when the maintenance window is opened. By default, the maintenance window opens every night from 10 P.M. to 6 A.M. and all day on weekends. The GATHER_STATS_JOB continues until it finishes, even if it exceeds the allocated time for the maintenance window. The default behavior of the maintenance window can be changed.
Запланированный джоб GATHER_STATS_JOB:

SQL> select owner, job_name, program_name, enabled from dba_scheduler_jobs
where job_name='GATHER_STATS_JOB';


OWNER JOB_NAME PROGRAM_NAME ENABLED
---------- ------------------ -------------------- -----
SYS GATHER_STATS_JOB GATHER_STATS_PROG TRUE
Выключить Автоматический Сбор Статистики для Оптимизатора, можно отключив джоб:
SQL> exec dbms_scheduler.disable('GATHER_STATS_JOB');
PL/SQL procedure successfully completed.


SQL> select owner, job_name, program_name, enabled from dba_scheduler_jobs
where job_name='GATHER_STATS_JOB';


OWNER JOB_NAME PROGRAM_NAME ENABLED
---------- ------------------ -------------------- -----
SYS GATHER_STATS_JOB GATHER_STATS_PROG FALSE

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

begin
dbms_stats.gather_table_stats('SCOTT','EMP');
dbms_stats.lock_table_stats('SCOTT','EMP');
end;
/
Теперь, по этой таблице невозможно будет собрать статистику ни автоматически, ни вручную:

SQL>exec dbms_stats.gather_table_stats('SCOTT','EMP');

begin dbms_stats.gather_table_stats('SCOTT','EMP'); end;
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 13182
ORA-06512: at "SYS.DBMS_STATS", line 13202
ORA-06512: at line 2
Снять блокировку статистики:

dbms_stats.unlock_table_stats('SCOTT','EMP');

22 апреля 2008 г.

Statspack (9i) и Automatic Workload Repository (10g)

Для сбора информации о производительности базы данных в Oracle 9i использовался statspack, в Oracle 10g statspack эволюционировал в Automatic Workload Repository (Автоматически управляемый репозитарий рабочей нагрузки).

В Oracle 9i statspack устанавливался дополнительно скриптом spcreate.sql, который создавал пользователя perfstat, под которым и создавался пакет statspack и другие необходимые объекты.

В Oracle 10g Automatic Workload Repository устанавливается автоматически прямо в схеме SYS, и по умолчанию собирает статистику о производительности каждый час и хранит ее 7 дней.

В Oracle 9i, снимок (snapshot) делался с помощью пакета statspack:
exec statspack.snap;

В Oracle 10g используется новый пакет dbms_workload_repository:
exec dbms_workload_repository.create_snapshot;


Список снимков (snapshots) в Oracle 9i:
select * from stats$snapshot;

Список снимков (snapshots) в Oracle 10g:
select * from dba_hist_snapshot;


Для создания отчета на основе двух снимков, в Oracle 9i использовался скрипт:
SQL> @?/rdbms/admin/spreport.sql

В Oracle 10g используется скрипт, который может сгенерировать отчет и текстовом, и в html формате:
SQL> @?/rdbms/admin/awrrpt.sql

В Oracle 10g все эти операции, то есть сделать снимок, просмотреть список снимков, и создать отчет в формате html, можно проделать в Enterprise Manager Database Control или Grid Control.

19 апреля 2008 г.

Табличные пространства в Oracle 10g

В Oracle 10g появились следующие новые возможности по работе с табличными пространствами:

1) Возможность переименовать табличные пространства
2) Установка постоянного табличного пространства по умолчанию (default permanent tablespace)
3) Поддержка больших файлов (bigfile tablespaces)
4) Возможность переносить табличные пространства на другие платформы (cross platform transportable tablespaces)
5) Группы временных табличных пространств (temporary tablespace groups)
6) Передача файлов (DBMS_FILE_TRANSFER)

1) Возможность переименовать табличные пространства

SQL> select tablespace_name, count(*) from dba_segments where tablespace_name like 'USERS%' group by tablespace_name;

TABLESPACE_NAME COUNT(*)
------------------------------ ----------
USERS 43

SQL> alter tablespace users rename to users_new;

Tablespace altered

SQL> select tablespace_name, count(*) from dba_segments where tablespace_name like 'USERS%' group by tablespace_name;

TABLESPACE_NAME COUNT(*)
------------------------------ ----------
USERS_NEW 43


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

SQL> select tablespace_name, file_name from dba_data_files where tablespace_name like 'USERS%';

TABLESPACE_NAME FILE_NAME
------------------------------ --------------------------------------------------------------------------------
USERS D:\ORACLE\PRODUCT\ORADATA\TESTDB\USERS01.DBF

SQL> alter tablespace users rename to users_new;

Tablespace altered

SQL> select tablespace_name, file_name from dba_data_files where tablespace_name like 'USERS%';

TABLESPACE_NAME FILE_NAME
------------------------------ --------------------------------------------------------------------------------
USERS_NEW D:\ORACLE\PRODUCT\ORADATA\TESTDB\USERS01.DBF


Табличные пространства SYSTEM и SYSAUX нельзя переименовать таким образом.

SQL> alter tablespace sysaux rename to sysaux2;

alter tablespace sysaux rename to sysaux2

ORA-13502: Cannot rename SYSAUX tablespace

SQL> alter tablespace system rename to system2;

alter tablespace system rename to system2

ORA-00712: cannot rename system tablespace

При переименовании табличного пространства UNDO, ссылка на него в файле параметров тоже автоматически меняется после перегруза, если используется spfile.
Если экземпляр был старторван с pfile, но в alert.log выводится напоминание вручную обновить pfile.

SQL> show parameter pfile

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string D:\ORACLE\PRODUCT\10.2.0\DATAB
ASE\SPFILETESTDB.ORA
SQL>
SQL> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SQL>
SQL> alter tablespace undotbs1 rename to undotbs_new;

Tablespace altered.

SQL>
SQL>
SQL> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SQL>
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 612368384 bytes
Fixed Size 1292036 bytes
Variable Size 348129532 bytes
Database Buffers 255852544 bytes
Redo Buffers 7094272 bytes
Database mounted.
Database opened.
SQL>
SQL> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS_NEW
SQL>


2) Установка постоянного табличного пространства по умолчанию (default permanent tablespace)

SQL> alter database default tablespace example;

Database altered

SQL> select property_name, property_value from database_properties where property_name like 'DEFAULT_PERMANENT_TABLESPACE%';

PROPERTY_NAME PROPERTY_VALUE
------------------------------ --------------------------------------------------------------------------------
DEFAULT_PERMANENT_TABLESPACE EXAMPLE

SQL> create user rahat identified by agivetova;

User created

SQL> select username, default_tablespace from dba_users where username ='RAHAT';

USERNAME DEFAULT_TABLESPACE
------------------------------ ------------------------------
RAHAT EXAMPLE




3) Поддержка табличных пространств состоящих из большого файла (bigfile tablespaces)

Одним из основных новинок в работе с табличными пространствами в Oracle 10g являются поддержка больших файлов.
Табличные пространства bigfile состоят только из 1 файла данных, который может расти до 128TB в зависимости от размера блока.
Например, если размер блока табличного пространства 8К, то табличное пространство может расти до 32ТВ.
Внизу таблица с максимальными размерами табличных пространств в зависимости от размера блока:

Размер блока табличного пространства Максимальный размер табличного пространства
2K 8TB
4K 16TB
8K 32TB
16K 64TB
32K 128TB

В представление dba_tablespaces добавлено поле bigfile, которое указывает, является ли табличное пространство - bigfile tablespace.

SQL> select tablespace_name, bigfile from dba_tablespaces;

TABLESPACE_NAME BIGFILE
------------------------------ -------
SYSTEM NO
UNDOTBS_NEW NO
SYSAUX NO
TEMP NO
USERS NO
EXAMPLE NO

6 rows selected

SQL> create bigfile tablespace big_users datafile 'D:\ORACLE\PRODUCT\ORADATA\TESTDB\BIG_USERS01.DBF' size 10M autoextend on next 10M;

Tablespace created

SQL> select tablespace_name, bigfile from dba_tablespaces;

TABLESPACE_NAME BIGFILE
------------------------------ -------
SYSTEM NO
UNDOTBS_NEW NO
SYSAUX NO
TEMP NO
USERS NO
BIG_USERS YES
EXAMPLE NO

7 rows selected


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


SQL> alter tablespace big_users add datafile 'D:\ORACLE\PRODUCT\ORADATA\TESTDB\BIG_USERS02.DBF' size 20M;

alter tablespace big_users add datafile 'D:\ORACLE\PRODUCT\ORADATA\TESTDB\BIG_USERS02.DBF' size 20M

ORA-32771: cannot add file to bigfile tablespace


По умолчанию, все табличные пространства создаются c smallfile, но эту настройку можно изменить следующей командой:


SQL> select property_name, property_value from database_properties where property_name like 'DEFAULT_TBS_TYPE';

PROPERTY_NAME PROPERTY_VALUE
------------------------------ --------------------------------------------------------------------------------
DEFAULT_TBS_TYPE SMALLFILE

SQL> alter database set default bigfile tablespace;

Database altered

SQL> select property_name, property_value from database_properties where property_name like 'DEFAULT_TBS_TYPE';

PROPERTY_NAME PROPERTY_VALUE
------------------------------ --------------------------------------------------------------------------------
DEFAULT_TBS_TYPE BIGFILE


Теперь, команда create tablespace будет создавать bigfile табличные пространства.

16 апреля 2008 г.

Ошибка после установки патча 10.2.0.3

После апгрейда 10.2.0.1 до 10.2.0.3, база не поднялась с такой ошибкой:

ORA-00202: control file: '/zones/u01/app/oracle/oradata/OASDB/control01.ctl'
ORA-27037: unable to obtain file status
SVR4 Error: 25: Inappropriate ioctl for device


Платформа: Solaris 10. Вырезка из металинка:
"The 10.2.0.3 patchset code changes attempted to use directio() calls in a manner not supported by the filesystem.

This issue affects VxFS filesystems which are typically managed by Veritas or Solstice. This issue may also affect QFS filesystems and SAM-FS filesystems. It is not known to affect UFS filesystems even if they are managed by Veritas or Solstice."

Решение: установка пачта 5752399.

5 апреля 2008 г.

Block Change Tracking в Oracle 10g

Новая опция block change tracking в Oracle 10g позволяет отслеживать измененные блоки, чтобы при инкрементальном бэкапе через RMAN, не нужно было сканировать весь датафайл, чтоб отыскать измененные блоки, тем самым уменьшая время выполнения инкрементального бэкапа.

Чтобы включить эту опцию нужно выполнить следующую команду:
alter database enable block change tracking using file '/u01/app/oracle/admin/TESTDB/rman/block_change.log';

Это команда запустит новый background process CTRW (Change Tracking Writer), который будет логировать блоки, измененные с момента последнего бэкапа, в файл block_change.log.

Далее, можно увидеть статус отслеживания измененных блоков:
select * from v$block_change_tracking;

Выключение опции:
alter database disable block change tracking;

4 апреля 2008 г.

Подключение к iSQL*Plus как SYSDBA или SYSOPER в Oracle 10g

О подключении к iSQL*Plus как SYSDBA или SYSOPER в Oracle 9i можно почитать здесь.
На http://hostname:5560/isqlplus невозможен доступ под SYSDBA или SYSOPER, если даже в Connect Identifier допишите "as sysdba" после названия базы данных:
ERROR - ORA-28009: connection as SYS should be as SYSDBA or SYSOPER

Чтобы подключиться к iSQL*Plus как SYSDBA или SYSOPER, нужно воспользоваться ссылкой http://hostname:5560/isqlplus/dba.
По умолчанию, доступ к этому URL закрыт, а при попытке попасть получите сообщение:

"Для входа на сервер по адресу iSQL*Plus DBA нужны имя пользователя и пароль. ..."

Для того, чтобы разрешить пользователю подключаться URL к iSQL*Plus DBA, нужно с помощью утилиты JAZN (Java AuthoriZatioN):

1) Создать пользователя для iSQL*Plus DBA URL
2) Назначить ему роль webDba
3) Выйти из jazn и при необходимости перегрузить iSQL*Plus.

Запуск утилиты jazn:

D:\>set ORACLE_HOME=D:\oracle\product\10.2.0

D:\>set JAVA_HOME=%ORACLE_HOME%\jdk

D:\>cd %ORACLE_HOME%\oc4j\j2ee\isqlplus\application-deployments\isqlplus

D:\oracle\product\10.2.0\oc4j\j2ee\isqlplus\application-deployments\isqlplus>%JAVA_HOME%\bin\java -Djava.security.properties=%ORACLE_HOME%\oc4j\j2ee\home\config\jazn.security.props -jar %ORACLE_HOME%\oc4j\j2ee\home\jazn.jar -user "iSQL*Plus DBA\admin" -password welcome -shell

JAZN:>
В unix среде команды аналогичные, только нужно заменить % на $, set на export, и слэши.
JAZN:> adduser "iSQL*Plus DBA" urldba urlpasswd
JAZN:>
JAZN:> listusers
iSQL*Plus DBA/admin
iSQL*Plus DBA/urldba
JAZN:>
JAZN:> grantrole webDba "iSQL*Plus DBA" urldba
JAZN:> exit
Тепер, при входе в http://hostname:5560/isqlplus/dba можно ввести логин (urladmin) и пароль пользователя (urlpasswd) и попасть в iSQL*Plus DBA URL, где есть возможность подключиться к базе данных как SYSDBA и SYSOPER.

22 ноября 2007 г.

Роль CONNECT в 10g

Только сегодня заметила, что в 10g роль CONNECT лишили всех системных привилегий, оставили только CREATE SESSION.

...beginning in Oracle Database 10g Release 2 (10.2), the CONNECT role has only the CREATE SESSION privilege, all other privileges are removed.

Объясняют это тем, что:
"Making this change enables new and existing database customers to enforce good security practices more easily."