mirall: (job)
Не прошло и сколько-то десятилетий, как - та-дам! - имена объектов Oracle могут быть длиннее 30 символов. Ну и ещё немножко ништяков.

https://community.oracle.com/docs/DOC-1008706
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: (job)
Некоторое время назад потребовалось сделать бэкап базы данных на RAC. Задача, на самом деле, вполне тривиальная, если бы не несколько но: у заказчика паранойя по поводу безопасности (не удивительно и понятно), у заказчика нет своего DBA (ну так уж вышло) и у меня есть доступ только к консоли сервера с базой данных. Таким образом, пришлось отказаться от использования красивого и удобного Enterprise Manager и придумать банальные консольные скрипты. И вот тут-то и возникла загвоздка.

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

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

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

Примерно так )
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.

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 Sep. 25th, 2017 06:12 am
Powered by Dreamwidth Studios