24 марта 2008 г.

Создание Enhancement Request (Запрос на Улучшение)

Если вы считаете, что в продуктах Oracle не хватает функциональности, которая была бы очень полезна, то можете завести Enhancement Request через Metalink. Не факт, что каждый созданный Enhancement Request будет вообще принят, и если даже будет принят, Oracle не обещает, что оно появиться в следующей версии продукта.
Это из металинка Note:214168.1:

"Customers can only file enhancement requests from MetaLink.

Please be aware that not all Enhancement Requests will be approved. The most common reason why an Enhancement is refused is because it is not in line with Oracle’s future product direction. ...
For Enhancement Requests that are approved for future releases, there is no guarantee that the Enhancement will take place in any specific release."


Как завести Запрос на Улучшение?
Логинитесь в Metalink, переходите в Service Request. Дальше нажимаете на Create SR, в появившемся окне указываете информацию о продукте в Product Description, а в блоке Problem Summary выбираете в Type of Problem -> Product Enhancement Request и описываете свои пожелания.

Например такой запрос на улучшение:
"Почему бы Ораклу не сделать возможным переименование пользователя одной командой?"
Один из моих моих хороших знакомых ДБА написал скрипт, который бы переименовал пользователя путём апдейта системных таблиц. Я сама скрипт еще не видела, но безопасно ли таким образом переименовывать пользователя в продуктивной базе данных?
Именно по этому вопросу уже существует Enhancement Request под номером 158508, но так как есть workaround к нему, Oracle считает, что пользователи пока могут и так обойтись:
Это из Note:14013.1:
Can you rename a user through Oracle?
Enhancement Request 158508.
Common workaround(s):
a - Do a user-level export of user A.
create new user B.
import dba/dba_passwd fromuser=A touser=B
drop user A.


Но например такой Enhancement Request (тоже из Note:14013.1):
Can you rename a tablespace?
Enhancement Request 148742.
Common workaround(s):
a - Export all of the objects from the tablespace.
Drop the tablespace including contents.
Recreate the tablespace.
Import the objects back in.


Наверно благодаря этому Enhancement Request возможность переименовать табличное пространство появилась в версии 10g:
ALTER TABLESPACE <oldname> RENAME TO <newname>;

Как вы считаете, какой функциональности не хватает в RDBMS Oracle?
Кстати, я перевела "Enhancement Request" как "Запрос на Улучшение"? Если у кого-то есть идеи получше, напишите о них.

Создание standby с помощью rman

Поднятие standby из бэкапа с помощью rman имеет ряд преимуществ:
1) не нужно останавливать основную базу
2) не повлияет на производительность основной базы данных

Здесь я опишу главные моменты, где идет отличие от ручного поднятия standby. Предполагается, что настройка параметров инициализации для основной и резеврной БД, и другие моменты, уже знакомы.

И так, если еще нет полного бэкапа основной БД, то нужно ее забэкапить:
rman target / catalog rman/mypassword@RMCAT
RUN {
ALLOCATE CHANNEL ch1 TYPE 'SBT_TAPE';
CROSSCHECK ARCHIVELOG ALL;
BACKUP
INCREMENTAL LEVEL=0
FILESPERSET 5 FORMAT 'bk_%s_%p_%t'
DATABASE include current controlfile for standby;
BACKUP FORMAT 'al_%s_%p_%t' ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch1;
}


Дальше, на резервном сервере, после поднятия резервной БД в nomount:
rman
connect catalog rman/password@CATDB
connect target sys/"mypassword"@mydb
connect auxiliary /
run{
ALLOCATE AUXILIARY CHANNEL c1 TYPE 'SBT_TAPE' parms="ENV=(NB_ORA_CLIENT=primary_host, NB_ORA_SERV=backupsrv)";
duplicate target database for standby dorecover NOFILENAMECHECK;
}


Здесь список ошибок, которые могут возникнуть, и их решения:
Ошибка №1:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on c1 channel at 03/24/2008 19:59:18
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 2


Это из документации Oracle:
"The most important line of the error output is the ORA-27211 error. It indicates the basic problem, that the media management library could not be loaded. ......By default, the database expects to find the media management library at $ORACLE_HOME/lib/libobk.so on UNIX, or %ORACLE_HOME%/bin/orasbt.dll on NT."

Решение от Виталия Воронцова, Oracle DBA и продвинутого пользователя по Netbackup:
слинковать библиотеку Netbackupа
oracle@myhost$ ./usr/openv/netbackup/bin/oracle_link
Mon Mar 24 20:09:47 UZT 2008
All Oracle instances should be shutdown before running this script.
Please log into the Unix system as the Oracle owner for running this script
Do you want to continue? (y/n) [n] y
LIBOBK path: /usr/openv/netbackup/bin
ORACLE_HOME: /u01/app/oracle/product/9.2.0.7.0
Oracle version: 9.2.0.7.0
Linking LIBOBK:
ln -s /usr/openv/netbackup/bin/libobk.so64.1 /u01/app/oracle/product/9.2.0.7.0/lib/libobk.so
Done
Please check the trace file located in /tmp/make_trace.6960
to make sure the linking process was successful.


Ошибка №2:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 03/25/2008 17:49:18
RMAN-03015: error occurred in stored script Memory Script
ORA-19507: failed to retrieve sequential file, handle="bk_15539_1_650240673", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
Failed to process backup file

Это из документации Veritas NetBackup 6 for Oracle: System Administrator's Guide:

"Ensure that the NetBackup server is configured to allow a redirected restore. The administrator can remove restrictions for all clients by creating the following file on the Netbackup master server:
/usr/openv/netbackup/db/altnames/No.Restrictions
Or, to restrict clients to restore only from certain other clients, create the following file:
/usr/openv/netbackup/db/altnames/client_name
Where client_name is the name of the client allowed to do the redirected restore (the destination client). Then, add the name of the NetBackup for Oracle source client to that file."

21 марта 2008 г.

Установка OAS 10g на Windows Vista

Установка Oracle Application Server 10g на Windows Vista завершилась безуспешно:

Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be 5.0, 5.1 or 5.2 . Actual 6.0
Failed <<<<

Exiting Oracle Universal Installer, log for this session can be found at C:\User
s\Raku\AppData\Local\Temp\OraInstall2008-03-22_02-00-54AM\installActions2008-03-
22_02-00-54AM.log

Please press Enter to exit...


Жаль, что OAS10g не поддерживается в Windows Vista. Конечно можно обойти это, добавив в файле oraparam 6.0: Windows=5.0,5.1,5.2,6.0, но не факт, что будет работать без неприятных сюрпризов.

Временный останов передачи архивных логов на standby

останов:
alter system set log_archive_dest_state_?='defer' scope=both;

возобновление:
alter system set log_archive_dest_state_?='enable' scope=both;

19 марта 2008 г.

ORA-01630

ORA-01630: max # extents (505) reached in temp segment in tablespace TEMP2

Решение:
ALTER TABLESPACE SYSTEM default storage (MAXEXTENTS UNLIMITED);
либо пересоздать temporary tablespace - locally managed tablespace.

13 марта 2008 г.

Проблемы с listener ORA-12535: TNS:operation timed out в Oracle 9i

Одной из причин таких ошибок в часы пик может быть то, что листенер всего-навсего не успевает обработать поступающие запросы на подключение.
Например, когда одновременно запускаются очень много клиентских джобов, которые все в один момент обрушиваются на листенер, листенер успевает обработать только первые поступившие запросы, а остальные падают с ошибкой ORA-12535.

Для борьбы с ними можно попробовать следующие варианты:

1) Параметр INBOUND_CONNECT_TIMEOUT
Можно попробовать установить параметр в файле listener.ora: INBOUND_CONNECT_TIMEOUT_ = 600
Этот параметр задает кол-во секунд, в течение которых должна быть завершена обработка запроса клиента. Если за указанное время листенер не успевает обработать запрос клиента на подключение, он выдает ошибку ORA-12535 и обрывает соединение с клиентом.
Это аналог параметра CONNECT_TIMEOUT, который является устаревшим в версии 9i.

Еще можно попробовать в файле sqlnet.ora добавить параметр:
SQLNET.INBOUND_CONNECT_TIMEOUT = 700

2) Параметр QUEUESIZEС помощью этого параметра можно установить кол-во запросов, которые может обрабатывать листенер одновременно.

LISTENER_TESTDB =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(Host = myhost)(Port = 2483)(QUEUESIZE=200))
)
SID_LIST_LISTENER_TESTDB =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TESTDB)
(ORACLE_HOME = /testdb/u01/app/oracle/product/9.2.0.8.0)
(SID_NAME = TESTDB)
)
)

3) Поднятие дополнительных листенеров
Установка параметров INBOUND_CONNECT_TIMEOUT и QUEUESIZE не всегда может помочь, так как листенер работает с той же скоростью, а те запросы, которые ожидают подключения к базе, всего-навсего будут дольше удерживаться, пока не рассосется очередь. Но если очередь все-таки не рассосется за указанное время, клиенты опять упадут с ошибкой ORA-12535.

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

И так, на сервере поднимаем 2 листенера на 2 разных портах 2483 и 2484.
В файле listener.ora прописываем:

LISTENER_TESTDB =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(Host = myhost)(Port = 2484))
)
SID_LIST_LISTENER_TESTDB =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TESTDB)
(ORACLE_HOME = /testdb/u01/app/oracle/product/9.2.0.8.0)
(SID_NAME = TESTDB)
)
)

LISTENER_TESTDB2 =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(Host = myhost)(Port = 2483))
)
SID_LIST_LISTENER_TESTDB2 =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TESTDB2)
(ORACLE_HOME = /testdb/u01/app/oracle/product/9.2.0.8.0)
(SID_NAME = TESTDB2)
)
)


Запускаем листенеры:
oracle@myhost $ lsnrctl
LSNRCTL> start LISTENER_TESTDB
LSNRCTL> start LISTENER_TESTDB2

Теперь нужно на стороне клиента прописать в tnsnames.ora:
TESTDB =
(DESCRIPTION =
(ADDRESS_LIST =
(FAILOVER = ON)
(LOAD_BALANCE = ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = myhost)(PORT = 2483))
(ADDRESS = (PROTOCOL = TCP)(HOST = myhost)(PORT = 2484))
)
(CONNECT_DATA = (SERVICE_NAME = TESTDB))
)
Теперь можно в $ORACLE_HOME/network/log посмотреть размеры лог файлов каждого листенера. Они будут расти по мере обработки запросов на подключение.

oracle@myhost $ ls -la *.log