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: (bubble)
set sqlblanklines on

В смысле, игнорируем пустые строки.

Shutdown

Nov. 28th, 2012 03:12 pm
mirall: (job)
Оказывается, таки можно сделать
alter database close;
alter database dismount;

только нужно, чтобы сессий к базе не было.
mirall: (job)
Давно собиралась нарисовать запросик. Основная цель - организация каскадного удаления (или свойством on delete cascade внешнего ключа, или последовательностью опрераторов delete, - по желанию).
with refs as (
select uc.constraint_name
     , ucc1.table_name
     , ucc1.column_name
     , ucc2.table_name ref_tab
     , ucc2.column_name ref_col
     , uc.delete_rule
  from user_constraints uc
  join user_cons_columns ucc1 on uc.constraint_name = ucc1.constraint_name
  join user_cons_columns ucc2 on uc.r_constraint_name = ucc2.constraint_name and ucc1.position = ucc2.position
 where uc.constraint_type = 'R'
  order by ucc1.table_name
         , uc.constraint_name
)
select lpad (constraint_name, length(constraint_name) + (level-1)*4, ' '), table_name, column_name, ref_tab, ref_col, level, delete_rule
  from refs
  start with table_name = 'SOME_TBL'
  connect by nocycle ref_tab = prior table_name;

OVERLAPS

Feb. 17th, 2012 01:41 pm
mirall: (job)
Оказывается, в SQL есть оператор OVERLAPS. И это прекрасно.

Правда, это всего лишь частично прекрасно. Ибо в Oracle эта возможность является недокументированной. Тем не менее, она есть.
SQL> select 1 from dual
SQL>  where (sysdate - 1, sysdate + 1)
SQL>        overlaps
SQL>        (sysdate - 2, sysdate + 2);

         1
----------
         1
Зато в PostgreSQL оно существует вполне себе официально. И это ещё прекраснее.
# select ('-infinity', current_timestamp + interval '10 days')
         overlaps
         (current_timestamp - interval '1 days', current_timestamp + interval '1 days');
 overlaps
----------
 t
(1 row)
Кстати, PostgreSQL ещё знает, что такое бесконечность.
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: (Default)
[oracle@hostname ~] $ORACLE_HOME/OPatch/opatch lsinventory -details
mirall: (job)
    Если в условии поиска задать просто '%', то запрос ничего не вернёт. При этом условие 'ZZZ%' Отрабатывает корректно.
    Интересно, это баг или фича. Или просто у меня неудачно полнотекстовый индекс настроен конкретно для этой версии?
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)
Проблема была в следующем.
При подключении к RAC под пользователем sys, рандомно выпадала ошибки ORA-01017: invalid username/password; logon denied. Т.е. десять коннектов подряд могли семь раз соединиться нормально и три раза упасть.

Коллеги почему-то начали рыть в области case sensitivity имён пользователей в Oracle. "А может такое быть, что sys и SYS - это разные пользователи". По мне, такого быть не может.

А оказалось, что почему-то на разных экземплярах были выставлены разне пароли для sys. Когда подключение направлялось на первый узел кластера, коннектилось нормально. На второй - падало с ошибкой.

Пароль-то вернули на место. Но у меня до сих пор в голове не укладыватся, как такое возможно. Похоже, я в RAC понимаю ещё меньше, чем думала.
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)
Если DML на таблице виснет, то имеет смысл проверить, не забыл ли кто-нибудь сделать commit :)
mirall: (job)
    И случилась такая оказия, что понадобилось переехать датафайлы из файловой системы на ASM. Чтобы не забыть и потом лишний раз не гуглить, микромануал прилагается.
    Read more... )
Page generated Sep. 23rd, 2025 09:47 pm
Powered by Dreamwidth Studios