mirall: (job)
Давненько я стандартной утилитой экспорта/импорта не пользовалась, однако.

Не суть важно, с какого перепугу она вдруг понадобилась, а важно вот что.
Мелочи для памяти )
mirall: (job)
Оказывается, у оракла имеется чудная утилита adrci - часть системы Automatic Diagnostic Repository - управляющая всяческими диагностическими сообщениями и, в частности, контролирующая срок жизни разных трейсов.

Нежно и незамысловато

[oracle@my_server ~]$ adrci

ADRCI: Release 11.2.0.1.0 - Production on Mon Dec 2 23:58:50 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

ADR base = "/u01/app/oracle"
adrci> show homes
ADR Homes:
diag/rdbms/racdb/racdb
adrci> set home diag/rdbms/racdb/racdb
adrci> show control

ADR Home = /u01/app/oracle/diag/rdbms/racdb/racdb:
*************************************************************************
ADRID SHORTP_POLICY LONGP_POLICY LAST_MOD_TIME LAST_AUTOPRG_TIME LAST_MANUPRG_TIME ADRDIR_VERSION ADRSCHM_VERSION ADRSCHMV_SUMMARY ADRALERT_VERSION CREATE_TIME
-------------------- -------------------- -------------------- ---------------------------------------- ---------------------------------------- ---------------------------------------- -------------------- -------------------- -------------------- -------------------- ----------------------------------------
2076828979 7 14 2013-12-02 23:53:39.343434 +03:00 1 2 76 1 2012-08-30 15:44:14.777078 +04:00
1 rows fetched

adrci> set control (SHORTP_POLICY=7)
adrci>



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

Через пару деньков схожу проверю, как оно там что чистит. А то всё-таки сомнительно.

Жалко, что чистку alert.log надо настраивать средствами операционной системы.
mirall: (job)
А было так.

Начала падать ошибка ORA-01502: index 'MYTAB.MYTAB_PK' or partition of such index is in unusable state.

Незатейливый запросик select owner, index_name from dba_indexes where status = 'UNUSABLE' утверждал, что сломалось штук шесть индексов на одной и той же таблице. Оставим в стороне вопрос, почему они вдруг сломались, но чинить-то надо.

Вообще-то стандартное решение в этом случае - перестроить индекс. Но на попытки сделать alter index MYTAB.MYTAB_PK rebuild база грязно ругалась: ora-00054: resource busy and acquire with nowait specified or timeout expired, причём никто там никакие объекты не лочил, а то бы, конечно, я не менее грязно прибила сессию вручную. Однако, как уже было сказано, объект был совершенно свободен, но перестраиваться не желал.

И тут на помощь нам приходит магический пакет dbms_repare.

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

Увы, хотя проблема-то решена, как оно работает, я понять не успела. Но знаю хотя бы, что оно существует - и то хлеб.
mirall: (job)
Чтобы было.
SQL> $ORACLE_HOME/rdbms/admin/utlrp.sql
mirall: (job)
Кратенько.
1) Должен быть выставлен ORACLE_SID.
2) Должен быть выставлен ORACLE_HOME.
3) Если в переменной PATH, как в моём случае, имеется несколько путей к бинарникам оракла, то путь к серверным должен быть первым (а вообще-то первым у меня обычно стоит путь к клиенту).

Да, это безумие.
D:\oracle\product\11.2.0\dbhome_1\bin;D:\oracle\product\11.2.0\client_1;D:\oracle\product\11.2.0\agent_1\bin;D:\oraclexe\app\oracle\product\11.2.0\server\bin;
mirall: (job)
Некоторое время назад потребовалось сделать бэкап базы данных на RAC. Задача, на самом деле, вполне тривиальная, если бы не несколько но: у заказчика паранойя по поводу безопасности (не удивительно и понятно), у заказчика нет своего DBA (ну так уж вышло) и у меня есть доступ только к консоли сервера с базой данных. Таким образом, пришлось отказаться от использования красивого и удобного Enterprise Manager и придумать банальные консольные скрипты. И вот тут-то и возникла загвоздка.

Стандартное решение: написать скрипты бэкапа, настроить cron, который будет их вызывать по расписанию, и на этом успокоиться до тех пор, пока база таки не упадёт. Но поскольку мы имеем дело с кластером из нескольких нод, встал вопрос, на которой из них дёргать бэкап. На всех - как-то многовато. На одной - а что, если именно она-то и упадёт, а все остальные останутся в строю? По очереди - а что, если упадёт именно та, чья очередь делать бэкап как раз и наступила? На каком-нибудь третьем сервере - нету лишней железки для дополнительной базы данных.

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

Понятно, что изобретённое решение - это нецелевое использование любопытной фичи. Но получилось забавно.

Примерно так )
mirall: (Default)
[oracle@hostname ~] $ORACLE_HOME/OPatch/opatch lsinventory -details
mirall: (job)
Вышел где-то в сентябре. По непонятной причине я релиз пропустила, так что навёрстываю сейчас.

Первые впечатления.
1) Установка на Windows 7 выкидывает две ошибки типа The installer is unable to instantiate the file C:\Users\username\AppData\Local\Temp\{078E83D7-3FCC-4A72-903B-995C7CE44681}\KEY_XE.reg. The file does not appear to exist. Я, не мудрствуя лукаво, нажала "ОК" и, вроде, каких-то глобальных сложностей не получила. Впрочем, возможно это именно оно вылезло мне боком во время импорта.
2) Апгрейд с версии 10g предлагается делать методом экспорта/импорта. Ну, начать с того, что путь к файлам данных по умолчанию для 11g отличается от 10g. Соответственно, при импорте табличных пространств, если не уследить, всё посыпется с ошибками типа "каталог не существует". Ну и вообще как-то мне сильно не понравилось то зашкаливающее количество ошибок, которое выдал предлагаемый документацией сценарий. А потому я решила воспользоваться родным экспортом/импортом, заточенным под наше конкретное приложение.
3) В этом месте я влетела в новую непонятную ошибку

UDI-31626: операция сгенерировала ошибку ORACLE 31626
ORA-31626: job does not exist
ORA-39086: cannot retrieve job information
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3326
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4551
ORA-06512: at line 1

Логи сообщили, что ORA-30094: failed to find the time zone data file for version 11 in $ORACLE_HOME/oracore/zoneinfo. При этом каталог $ORACLE_HOME/oracore/zoneinfo существует и в нём даже что-то лежит. Сравнение с содержимым аналогичного каталога для Enterprise Edition показало, что не хватает много чего. Докинула, чего не хватало. Заработало.

Интересно, как оно встанет на CentOS.
mirall: (job)
Monitoring Index Usage

Oracle Database provides a means of monitoring indexes to determine whether they are being used. If an index is not being used, then it can be dropped, eliminating unnecessary statement overhead.

To start monitoring the usage of an index, issue this statement:

ALTER INDEX index MONITORING USAGE;

Later, issue the following statement to stop the monitoring:

ALTER INDEX index NOMONITORING USAGE;

The view V$OBJECT_USAGE can be queried for the index being monitored to see if the index has been used. The view contains a USED column whose value is YES or NO, depending upon if the index has been used within the time period being monitored. The view also contains the start and stop times of the monitoring period, and a MONITORING column (YES/NO) to indicate if usage monitoring is currently active.

Each time that you specify MONITORING USAGE, the V$OBJECT_USAGE view is reset for the specified index. The previous usage information is cleared or reset, and a new start time is recorded. When you specify NOMONITORING USAGE, no further monitoring is performed, and the end time is recorded for the monitoring period. Until the next ALTER INDEX...MONITORING USAGE statement is issued, the view information is left unchanged.
mirall: (job)
Не знаю, зачем её гасили, но завести снова не смогли.
Симптомы

$ srvctl start database -d ractest1
PRCR-1079 : Failed to start resource ora.ractest1.db
ORA-00119: invalid specification for system parameter %s
CRS-2674: Start of 'ora.ractest1.db' on 'racnode01' failed
CRS-2632: There are no more servers to try to place resource 'ora.ractest1.db' on that would satisfy its placement policy
ORA-00119: invalid specification for system parameter %s
CRS-2674: Start of 'ora.ractest1.db' on 'racnode02' failed

Мутно и невнятно. Лог сообщал, что USER (ospid: 4216): terminating the instance due to error 119 (за pid не поручусь, но смысл именно такой).

Путём несложных преобразований (старт экземпляра локально из sqlplus, свежеобретённый полный, а не ссылочный pfile) выяснилось, что всё плохо в области remote_listener, каковой, вообще-то, был, по идее, в порядке, т.е. содержал нужное значение hostname:port.

Дальше я пошла кружным путём: ковыряла spfile. Сбросила remote_listener, после чего база завелась, но к ней всё ещё невозможно было подконнектиться. Попутно обнаружилось, что spfile проехал почему-то не из ASM, а из файловой системы. Пофиксилось пересозданием.

Потом попыталась вернуть remote_listener к исходному значению, не удалось, hostname базе всё ещё не нравился. Зато именно в этот момент начали падать осмысленные ошибки, которые уже нормально гуглились.

В результате обнаружилось, что в sqlnet.ora на обоих узлах должно быть прописано NAMES.DIRECTORY_PATH=(TNSNAMES,EZCONNECT), а у нас было NAMES.DIRECTORY_PATH=(TNSNAMES). Смешно и неудобно. Несколько часов возни, а в результате - изменить одну строчку.
mirall: (job)
    И случилась такая оказия, что понадобилось переехать датафайлы из файловой системы на ASM. Чтобы не забыть и потом лишний раз не гуглить, микромануал прилагается.
    Read more... )
mirall: (Default)
    Это баг.
    В общем, постоянно вылетала ошибка "ORA-04068: existing state of packages has been discarded", причём пакеты ошибок не содержат, компилируются успешно и вообще всё в шоколаде.
    Металинк утверждает, что это баг за номером 6485664 (нода 1058873.1). "Please note that the particularity of this bug is that it will cause a discrepancy in memory (library cache) only while information in the data dictionary (dependency$) remains consistent. This should differentiate it from other bugs where the same errors are produced but the dictionary itself becomes inconsistent due to timestamp mismatches between dependency$ and obj$."
    Впервые в жизни патчила RAC на RedHat.
mirall: (job)
Скрипты )
mirall: (job)
Скрипты )

Listener

Oct. 6th, 2010 12:31 pm
mirall: (job)
    Досадная не очень заметная мелочь.
    Oracle 11.2 по умолчанию настроил мне listener и базу на localhost. Понятно, что локально всё работало как часики, а вот извне, как оказалось, законнектиться было невозможно. Отсюда мораль: явно прописывать имя сервера.
mirall: (job)
    ОС Windows. Вдогонку, так сказать. )

Profile

mirall: (Default)mirall

July 2017

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 24th, 2017 12:46 pm
Powered by Dreamwidth Studios