dbaks

Предварительное замечание: если (вдруг) используется windows предварительно нужно создать новый экземпляр с помощью oradim. Итак: export ORACLE_SID=mysid Создаём pfile с необходимыми параметрами cat > initmysid.ora <<EOF db_name=yourdbname db_unique_name=instance EOF В большинстве случаев этого достаточно startup nomount Восстанавливаем controlfile из имеющейся резервной копии. RMAN> restore controlfile from '/home/oracle/stage/o1_mf_s_819826669_8x7w7g70_.bkp'; shutdown immediate startup mount; Сообщаем базе, где лежат резервные копии: RMAN> catalog start with '/home/oracle/stage'; Перед тем как восстанавливать БД неплохо было бы узнать последний хороший scn, дабы уберечься от ошибки на последней стадии (alter database open resetlogs ). Самый простой способ сделать это такой - после восстановления контрольного файла подключаемся as sysdba к mount базе и выполняем следующий запрос: SQL> column scn format 999999999999999 se

Задача: тестирование возможного выигрыша в производительности при использовании NATIVE COMPILATION по сравнению с  INTERPRETED COMPILATION. Методика тестирования. Процедура  TEST_PCG  реально боевая (название изменено) - делает много чего и долго. Код по понятным причинам приводить не буду. Для замера времени перед выполнение будет запускаться PROFILER. Процедура из пакета буде выполнена по 20 раз для обоих видов компиляции. -- test_block.sql DECLARE   L_COMPILED VARCHAR2(100);   L_TEST_PARAMS  VARCHAR2(100)  := 'TEST VALUES' BEGIN    FOR I IN 1..20   LOOP    SELECT DISTINCT PLSQL_CODE_TYPE INTO L_COMPILED FROM USER_PLSQL_OBJECT_SETTINGS WHERE NAME = 'TEST_PCG';   DBMS_PROFILER.START_PROFILER('TRY_TEST_PCG_COMPILED_'||v_compiled,1);      DBAX. TEST_PCG . TEST_PRC(TEST_PARAMS) ;   COMMIT;      DBMS_PROFILER.STOP_PROFILER;   END LOOP; END; / SQL> alter procedure p1 compile plsql_code_type=interpreted; SQL> @test

Черновик: взять source: https://github.com/postgrespro/postgres скомпилировать: http://orabase.org/index.php/2015/07/21/postgrespro-pg_stat_wait-patch/ У меня получилось не сразу. Позже сделаю свою хау-ту. Обратить внимание на параметры configure: ./configure --with-ldap --with-perl --with-python --with-openssl --with-libxml --prefix=/usr/pgsql-pro --exec-prefix=/usr/pgsql-pro vim postgresql.conf shared_preload_libraries='pg_stat_wait' waits_monitoring = on pg_stat_wait.history = on pg_stat_wait.history_size = 1000000 pg_stat_wait.history_period = 1000 psql  -c  CREATE EXTENSION pg_stat_wait см. таблицы: pg_stat_wait_current  pg_stat_wait_history  pg_stat_wait_profile еще инфа по теме: https://simply.name/ru/pg-stat-wait.html http://www.highload.ru/2015/abstracts/1902.html

Предварительные требования:  1. Компилятор C. Как правило имеется в виду gcc и g++ gcc  --version на CENTOS 7 мне понадобился gcc_c++ (в дополнение к установленному ранее gcc) 2. JAVA. Убедиться, что  javac  -version работает  3. PostgreSQL установлен и  работает pg_config Файлы для разработки (.h файлы) для нашего PostgreSQL также должны быть установлены. Убедиться можно посмотрев что лежит в INCLUDEDIR-SERVER (вывод pg_config). Я раньше компилировал БД из исходников на этой машине, так что у меня эти файлы были. 4. компилятор Maven mvn --version Установка git clone https://github.com/tada/pljava.git или git clone ssh://git@github.com/tada/pljava.git Заходим в директорию pljava и выполняем mvn clean install В результате должны получить: [INFO] PostgreSQL PL/Java ................................ SUCCESS [INFO] PL/Java API ....................................... SUCCESS [INFO] PL/Java backend Java code ......................... SUCCESS [INFO] P

Рекомендации по результатам расследования инцидента с повреждёнными блоками на промышленном кластере. Рекомендации orachk (раздел Maximum Availability Architecture (MAA) Scorecard): Провести настройку параметров: DB_BLOCK_CHECKSUM=FULL DB_LOST_WRITE_PROTECT=TYICAL/FULL DB_BLOCK_CHECKING=MEDIUM/FULL To achieve the most comprehensive data corruption prevention and detection , use Oracle Active Data Guard and configure DB_BLOCK_CHECKSUM,DB_LOST_WRITE_PROTECT and DB_BLOCK_CHECKING database initialization parameters on the primary database and all standby databases in a Data Guard environment. Установку этих параметров по отдельности можно заменить на установку единого параметра DB_ULTRA_SAFE: DATA_ONLY - эквивалент: DB_BLOCK_CHECKING = MEDIUM. DB_LOST_WRITE_PROTECT = TYPICAL. DB_BLOCK_CHECKSUM = FULL. DATA_AND_INDEX - эквивалент: DB_BLOCK_CHECKING = FULL. DB_LOST_WRITE_PROTECT = TYPICAL. DB_BLOCK_CHECKSUM = FULL. Для установки степени влияния указанных

Перемещать будем с "C:\\oracle\\product\\12.1.0" в "D:\\oracle\\product\\12.1.0". Экземпляр БД называется DBAX. Заходим на сервера под локальным администратором (по совместительству в группе ora_dba). Экземпляр пока может работать. xcopy  C:\\oracle\\product\\12.1.0 D:\\oracle\\product\\12.1.0 Дожидаемся окончания процесса Открываем первое окно с cmd и выполняем: C:\>set ORACLE_HOME=C:\\oracle\\product\\12.1.0 C:\>set PATH=C:\\oracle\\product\\12.1.0\\OPatch;C:\\oracle\\product\\12.1.0\\bin;%PATH% C:\>opatch version C:\>opatch lsinventory Открываем второе окно с командной строкой: D:\>set PERL5LIB=D:\\oracle\\product\\12.1.0\\perl\\lib D:\>set PATH=D:\\oracle\\product\\12.1.0\\perl\\5.8.3\\bin\\MSWin32-x86-multi-thread;%PATH% D:\>perl %ORACLE_HOME\clone\bin\clone.pl ORACLE_HOME="D:\\oracle\\product\\12.1.0" ORACLE_HOME_NAME="OraDB11gR1_home" ORACLE_BASE="D:\\oracle" Убеждаемся, что: The cloning

В Oracle 12c появилась новая возможность: перемещение файлов данных он-лайн. Это относится даже к файлам пространства SYSTEM. select file_name from dba_data_files where tablespace_name = 'SYSTEM'; FILE_NAME                                                            ------------------------------------------------------------------- /app/oracle/oradata/dbax/system01.dbf                                         1 row selected. ALTER DATABASE MOVE DATAFILE '/app/oracle/oradata/dbax/system01.dbf' TO '/u01/oradata/dbax/system01.dbf'; Database altered. select file_name from dba_data_files where tablespace_name = 'SYSTEM'; FILE_NAME                                                            -------------------------------------------------------------------- /u01/oradata/dbax/system01.dbf                                        1 row selected.

1. Узнать имена логических разделов: sudo lvs 2. Найти новый диск sudo fdisk -l 3. Создать раздел на новом диске: sudo fdisk /dev/sdb 4. Узнать тип файловой системы на расширяемом диске df -T 5. Отформатировать новый раздел sudo mkfs.xfs /dev/sdb1 6. Создать физический том в новом разделе sudo pvcreate /dev/sdb1 7. Узнать имя группы томов: sudo vgs 8. Добавить новый раздел к увеличиваемому: sudo vgextend vg_centos6 /dev/sdb1 9. Расширить логический раздел sudo lvextend -l +100%FREE /dev/mapper/vg_system-lv_root 10. Увеличить ФС: sudo xfs_growfs /

Задача: Измерение скорости построения индекса при различных степенях параллелизма. Для примера взята таблица размером 600 мегабайт. S ELECT SUM(BYTES)/1024/1024 MB FROM DBA_SEGMENTS WHERE OWNER = 'DBAX' AND SEGMENT_NAME = 'TEST1' AND SEGMENT_TYPE='TABLE';                  MB -------------------                 646 Для этой таблицы будет построен индекс по всем полям (для утяжеления операции). CREATE INDEX DBAX.TEST_I1 ON DBAX.TEST1(C1, C2, C3, C4, C5, C6); -- PARALLEL N Результаты: PARALLELISM     16 CPU         RAC(CPU 2x192) NOPARALLEL 01:00,3        00:21,0 PARALLEL 2 00:21,2        00:19,1 PARALLEL 4 00:12,3        00:11,0 PARALLEL 8 00:09,3        00:04,7 PARALLEL 16 00:08,7        00:03,0 PARALLEL 32 00:09,9        00:02,7 PARALLEL 64 00:19,0        00:03,4 PARALLEL 128    00:28,7         00:05,8 На 16 ядерном сервере сразу заметно уменьшение производительности при превышении значен

Заказчик подозревает проблемы в работе дисковой подсистемы своих центральных серверов БД. Задача: подтвердить или опровергнуть подозрение. Определение проблем в работе подсистеме ввода/вывода. События ожидания Oracle, свидетельствующие о наличии возможных проблем в дисковой подсистеме: • db file sequential read • db file scattered read • read by other session • db file async i/o submit • direct path read • direct path write / direct path write temp • db file parallel read • async disk IO | ksfd: async disk IO • control file sequential read Также о проблемах подсистемы ввода вывода могут свидетельствовать следующие события, связанные с обработкой REDO логов: • log file sync • log file switch completion • log file switch (checkpoint incomplete) • {ARCH | LGWR | LNS} wait on ATTACH • {ARCH | LGWR | LNS} wait on SENDREQ • {ARCH | LGWR | LNS} wait on DETACH • LGWR-LNS wait on channel Основным средством диагностики работы дисковой подсистемы и связа