dbaks

Задача: раз в сутки обновлять snapshot standby базу до актуального состояния. Делается это путем перевода в physycal standby и наката накопленных за день архивов.  После завершения обновления база снова переключается в snapshot standby. Для Windows: @echo off set ORACLE_SID=axtest set ORACLE_HOME=G:\oracle\ora11204 set prim_db=prd set std_db=std set cred=sys/p@S$w0Rd echo #################################################################### echo Refresh started at %time%  echo . echo #################################################################### set role = PHYSICAL %ORACLE_HOME%\bin\dgmgrl %cred%@%prim_db% "convert database %std_db% to %role% standby" echo  Now we are waiting for apply to finish. It'll take some time. echo ... :wait  ping 127.0.0.1 -n 30 >null %ORACLE_HOME%\bin\dgmgrl %cred%@%prd% "show database %std%" > log\lag.tmp for /f "tokens=3 delims= " %%i in ('find "Transport Lag" log\lag.tmp

Включение режима архивлог. CONNECT sys AS SYSDBA STARTUP MOUNT EXCLUSIVE -- really exclusive ? ALTER DATABASE ARCHIVELOG; -- NOARCHIVELOG to disable ARCHIVE LOG START; ALTER DATABASE OPEN; Список архивлогов, которые не были забекаплены list archivelog all backed up 0 times to disk/sbt_tape; Есть баг, когда Golden Gate держит архзивлоги, которые реально ему уже не нужны: RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process В таком случае, при острой необходимости можно их удалить с ключом force. Для пущей безопасности удалить можно только уже забекапленные логи и те, которые старше одного дня. delete force archivelog all backed up 1 times to device type sbt_tape completed before 'sysdate-1'; Как вытащить арихвлог из имеющегося бекапа. RMAN> run {  allocate channel t1 type 'sbt_tape';  set archivelog destination to 'C:\REPL';  restore archivelog sequence between 46435 and  46438 ;  release channel

Настройка 1. Настроен ли Flashback select flashback_on from v$database; FLASHBACK_ON ------------------ NO 2. Настройка FRA show parameter db_recovery_file_dest show parameter db_recovery_file_dest_size Если не настроена alter system set db_recovery_file_dest='+<FRA Diskgroup>' SCOPE=spfile; alter system set db_recovery_file_dest_size=100G SCOPE=spfile; 3. Настройка Flashback shutdown immediate; startup mount; alter database flashback on; alter database open; select flashback_on from v$database; FLASHBACK_ON ------------------ YES alter system set db_flashback_retention_target=2880; 4. Создание точки восстановления. CREATE RESTORE POINT before_upgrade; CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE; Откат изменений с использованием технологии flashback. CONN / AS SYSDBA SHUTDOWN IMMEDIATE STARTUP MOUNT EXCLUSIVE --не уверен, что обязательно exclusive ? FLASHBACK DATABASE TO RES

Планировщик двенадцатого оракла позволяет запускать задания основанные на скриптах (bash/rman). Это особенно удобно в среде RAC, так как расписание будет храниться в едином хранилище, а не в crontab каждого узла. В старых версиях тоже была возможность вызывать внешние скрипты, но для этого требовались определенные танцы с бубном. Сейчас же всё легко и просто. Для создания этих заданий требуются привилегии CREATE JOB, CREATE EXTERNAL JOB и  CREATE CREDENTIAL . 1.  Для начала нужно создать ссылку на учетную запись ОС. С этими правами и будет работать скрипт. BEGIN  DBMS_CREDENTIAL.create_credential(                          credential_name   => 'oracle_os',                          username          => 'oracle',                          password          => 'oracle'); END; / 2. Теперь можно создавать задание. В примере используется скрипт RMAN. DECLARE    l_job_name   VARCHAR2 (30);    l_script     VARCHAR2 (32767); BEGIN

При частом использовании датапампа возможно возникновение ошибок следующего вида: ORA-31634: job already exists ORA-31664: unable to construct unique job name when defaulted Причина в следующем: Системные таблицы относящиеся к старым заданиям датапампа не были удалены. "This error normally occurs when you do not specify a unique JOB_NAME for the DataPump job  and for some reason that JOB_NAME already exists in the database, or else if you are running many jobs at the same time (more than 99 jobs) and DataPump cannot create a new job." (MOS) Для решения проблемы: 1. Найти неработающие задания ДП. SELECT owner_name, job_name, operation, job_mode,     state, attached_sessions     FROM dba_datapump_jobs     where owner_name='SCHEMA' and state='NOT RUNNING' ORDER BY 1,2;  2. Найти соответствующие этим заданиям системные таблицы. SELECT o.status, o.object_id, o.object_type,            o.owner||'.'||object_name &quo

1. Создание табличного пространства под архив:   CREATE TABLESPACE FLASH_ARCH_TS datafile         SIZE 10M AUTOEXTEND ON NEXT 100M; 2. Создание архива с периодом хранения год: CREATE FLASHBACK ARCHIVE FLASH_ARCH TABLESPACE FLASH_ARCH_TS RETENTION 1 YEAR; 3. Выдача прав для использования архива:    GRANT FLASHBACK ARCHIVE ON FLASH_ARCH TO DBAX;    ALTER FLASHBACK ARCHIVE FLASH_ARCH SET DEFAULT; 4. Включение архива для новой таблицы: CREATE TABLE  FB_TEST  (   id          NUMBER,   text  VARCHAR2(50)    ) FLASHBACK ARCHIVE [FLASH ARCH];   или    ALTER TABLE FB_TEST FLASHBACK ARCHIVE [ FLASH_ARCH] ;  для уже существующей таблицы. 5. Тест. Пробуем вставить данные в таблицу, затем убеждается, что 5 секунда назад их не было. insert into  FB_TEST    values(1,'test'); commit; select * from  FB_TEST   AS OF  TIMESTAMP(SYSTIMESTAMP - INTERVAL '5' second); no rows selected 6. Изменение структуры alter table  FB_TEST    add (text2 varchar2(20))

Задача: Провести реимпорт данных с удаленного сервера. Задача осложняется слабым каналом, а также версией Oracle - Standart Edition One, которая не поддерживает datapump опции compression = all. Имя схемы передается в качестве параметра (%1) для пакетного файла. rem Считаем, что имя хоста совпадает с именем базы в TNS set rem_hst=REMOTE rem rem_dir - это data_pump_dir на удаленной машине. set rem_dir=oracle\ora11\RDBMS\log rem Login и пароль для net use'a set rem_usr=localhost\dbax set rem_psw=p@S$w0Rd rem Экспорт дампа и архивирование его через wmic. expdp  dbax/ p@S$w0Rd @%rem_hst% dumpfile=%1.dmp schemas=%1 logfile=%1.log reuse_dumpfiles=yes wmic /node:"%rem_hst%" /user:%rem_usr% /password:"%rem_psw%" process call create "zip E:\%rem_dir%\%1.zip E:\%rem_dir%\%1.dmp" rem Копирование с возобновлением в случае падения сети. net use \\%rem_hst%\e$ /user:%rem_usr% %rem_psw% :copy copy \\%rem_hst%\e$\%rem_dir%\%1.zip c:\app\oracle\da

Делал все по  этой   статье, с небольшими своими исправлениями. Ниже могут быть ошибки, неплохо бы перепроверить еще раз. Еще хорошая статья . Не проверял, но у него всегда все по делу. 1. Настройка Listner на обоих серверах. Нужна статическая регистрация. listener.ora LISTENER =   (DESCRIPTION_LIST =     (DESCRIPTION =       (ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))     )   ) SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = prd_DGMGRL) -- в 12c я обошелся без " _DGMGRL"       (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)       (SID_NAME = prd)     )   ) tnsnames.ora prd=   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = host1)(PORT = 1521))     )     (CONNECT_DATA =       (SID = prd)     )   ) std=   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = host2)(PORT = 1521))     )     (CONNECT_DATA =

1. Перемещение таблиц. SELECT      'ALTER TABLE '          || owner          || '.'          || segment_name          || ' MOVE TABLESPACE USERS;'   FROM   dba_segments  WHERE   tablespace_name = 'USERS2' AND segment_type = 'TABLE' 2. Перемещение LOB. SELECT      'ALTER TABLE '          || A.owner          || '.'          || TABLE_NAME          || ' MOVE LOB('          || COLUMN_NAME          || ') STORE AS (TABLESPACE USERS);'   FROM   dba_segments A, DBA_LOBS B  WHERE       a.tablespace_name = 'USERS2'          AND segment_type = 'LOBSEGMENT'          AND A.SEGMENT_NAME = B.SEGMENT_NAME 3. Перемещение индексов. SELECT      'ALTER INDEX '          || owner          || '.'          || segment_name          || ' REBUILD TABLESPACE USERS;'   FROM   dba_segments  WHERE   tablespace_name = 'USERS2' AND segment_type = 'INDEX' 4. Индек

1. После создания экземпляра правим /etc/oratab, а именно устанавливаем флажок рестарта в 'Y'. vim /etc/oratab AXDB:/app/oracle/product/12.1.0/dbhome_1:Y 2. Теперь из под root'a создаем файл  /etc/init.d/dbora вот с таким содержимым. #!/bin/sh # chkconfig: 345 99 10 # description: Oracle auto start-stop script. # # Set ORA_HOME to be equivalent to the $ORACLE_HOME # from which you wish to execute dbstart and dbshut; # # Set ORA_OWNER to the user id of the owner of the # Oracle database in ORA_HOME. ORA_HOME= /app/oracle/product/12.1.0/dbhome_1 ORA_OWNER=oracle if [ ! -f $ORA_HOME/bin/dbstart ] then     echo "Oracle startup: cannot start"     exit fi case "$1" in     'start')         # Start the Oracle databases:         # The following command assumes that the oracle login         # will not prompt the user for any values         # Remove "&" if you don't want startup as a background process.

Раньше для создания административного пользователя достаточно было выдать любому права dba. Но в 12c, с оздав пользователя: grant dba to c##dbax container=all; Подключившись с cdb$root и запросив gv$session получим отображение только сессий работающих в root'овом контейнере. Пользователь может видеть сессии работающие в других контейнерах только перейдя в соответствующий контейнер. alter session set container=axpdb1; В то же время, при подключении "sys as sysdba" запрос к gv$session возвращает сессии по всей базе. Хочется администрировать всю инфраструктуру, но не подключаться без нужды под sys'ом. Решение следующее . connect system@root  -- под sys ’ом не получилось. ALTER USER c##dbax SET CONTAINER_DATA = (CDB$ROOT,AXPDB1) FOR GV$SESSION CONTAINER=CURRENT; Тут мы разрешаем пользователю c##dbax во время нахождения в контейнере root просматривать информацию из gv$session касающуюся контейнеров CDB$ROOT и AXPDB1.

1. Setup Машина:  Oracle Linux 6.6; 2 Core VM; 4 GB RAM; База:  Oracle EE 12.1.0.2; SGA 2 Gb (Используется AMM); Inmemory size 1Gb; 2. Test TPC-H DBHammer . Ось X - номер запроса теста TPC-H, Y - время в секундах. Синим цветом показаны запросы inmemory, красным - обычные запросы. Выводы: заявленное многократное увеличение производительности не подтвердилось. Хотя, конечно нужно сделать скидку на убогость тестовой машины.

Установка PostgreSQL Последняя версия bash-скрипта для установки БД  тут . Но в чем-то он может быть сыроват, и гонять его не понимая "что и зачем" я бы не рекомендовал. 1. Запретить скачку плохих, негодных PG из стандартного репозитория: vi /etc/yum.repos.d/CentOS-Base.repo exclude=postgresql* 2. Затем установить хороший, годный PG репозиторий: yum localinstall http://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-1.noarch.rpm Перед этим, проверить по адресу  yum.postgresql.org актуальные по версии БД и обязательно по дистрибутиву ОС (например, для Centos и Oracle Linux нужны разные репозитории). 3. Установить сервер и другие нужные компоненты (рекомендуется devel и contrib): yum install postgresql94-server postgresql94-contrib postgresql94-devel или еще проще  yum install postgresql94* 4. Инициализировать базу: /usr/pgsql-9.4/bin/postgresql94-setup initdb 4'. Если требуется nondefault PGDATA (default = /var/lib/pgsql/9.4/data), делаем

Для настройки окружения в Linux можно все параметры базы указать в .bash_profile: ORACLE_HOME=/app/oracle/product/11.2.0.4/dbhome_1 export ORACLE_HOME ORACLE_BASE=/app/oracle export ORACLE_BASE ORACLE_SID=orcl export ORACLE_SID PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin export PATH Но лучше использовать для этих целей утилиту oraenv. oraenv берет данные из файла /etc/oratab orcl:/app/oracle/product/12.1.0/dbhome_1:N И на ее основе задает параметры окружения: ORACLE_SID, ORACLE_BASE,ORACLE_HOME и PATH Использовать можно в интерактивном режиме: . oraenv ORACLE_SID = [orcl] ? orcl The Oracle base has been set to /app/oracle И в неинтерактивном режиме. Добавить в  .bash_profile: ORACLE_SID=orcl ORAENV_ASK=NO . oraenv Для ASM ситуация аналогичная. . oraenv ORACLE_SID = [orcl] ? +ASM1 The Oracle base has been set to /u01/app/oracle echo $ORACLE_HOME /app/11.2.0/grid

1. Настроить ключи ssh для пользователя репликации 2. Настроить pg_hba.conf на master и  slave host  replication  all  192.168.0.1/32  trust host  replication  all  192.168.0.2/32  trust 3. На master: vi postgresql.conf wal_level = hot_standby max_wal_senders = 5 wal_keep_segments = 32 archive_mode    = on     archive_command = 'cp %p /path_to/archive/%f' 4. Клонировать master на  slave psql -c "SELECT pg_start_backup('label', true)" rsync -C -a --delete -e ssh --exclude postgresql.conf --exclude postmaster.pid \ --exclude postmaster.opts --exclude pg_log --exclude pg_xlog \ --exclude recovery.conf master_db_datadir/ slavedb_host:slave_db_datadir/ psql -c "SELECT pg_stop_backup()" или pg_basebackup -R -D /srv/pgsql/standby -h 192.168.0.1 -p 5432 5. На  slave : vi postgresql.conf hot_standby = on vi datadir/recovery.conf standby_mode          = 'on' primary_conninfo    

Установка pgAgent Последняя версия скрипта для установки агента  тут . Перенести инструкцию по агенту в отдельную тему. 1. Создать пользователя ОС, и сделать ему домашний каталог: useradd -s /bin/false -r -M pgagent mkdir /home/pgagent 2. Установить и настроить демон: yum install pgagent_94 При наличии ошибок вида (была на Oracle Linux 6.8) Error: Package: pgagent_94-3.4.0-1.rhel6.x86_64 (pgdg94)            Requires: libwx_baseu-2.8.so.0(WXU_2.8)(64bit) Нужно установить EPEL systemctl enable pgagent_94 chown pgagent:pgagent /var/log/pgagent_94.log 3. Установить схему агента в базе: sudo -u postgres psql -f /usr/share/pgagent_94-3.4.0/pgagent.sql postgres 4. Создать файл паролей для подключения агента к базе. vi /home/pgagent/.pgpass localhost:5432:*:postgres:postgres chown pgagent.pgagent /home/pgagent -R chmod 600 /home/pagent/.pgpass 5. Запустить и проверить работу агента systemctl start pgagent_94.service systemctl status pga