├── .gitattributes ├── Backup and recovery ├── Corruption │ └── block_recovery_from_standby.md ├── DataGuard Broker │ └── Physical_standby_database_disabled.md ├── Flashback database │ └── Включение Flashback Database │ │ └── README.md ├── Redo │ └── Частота переключения redo.sql ├── Undo │ └── undo_rollback_status.sql └── Операции с лентой │ └── Dummy SBT tape │ └── README.md ├── Cloud Control └── Compliance │ └── Disable_Security_Recommendations_For_Oracle_Products.md ├── Configuration ├── dblinks │ └── disable_all_dblink_usage.md └── listener │ └── samples │ ├── listener.ora │ └── tnsnames.ora ├── DataPump ├── Export │ └── sample_schema_export.par └── Import │ └── sample_schema_import.par ├── Events ├── acknowledge over PGA limit │ └── acknowledge over PGA limit.md ├── enq JI - contention │ └── enq JI - contention.md ├── enq SQ - contention │ └── enq SQ - contention.md ├── errorstack │ └── errorstack_trace_enable.md ├── event 10261.md ├── events_set_in_session.sql └── oradebug │ └── show_events_set_in_another_session.md ├── Installation └── Problems │ ├── INS-30131.md │ ├── error_invoking_target_agent_nmhs_of_makefile.md │ └── recreate_orainventory.md ├── Listener └── TNS- │ └── TNS-01189_The listener could not authenticate the user.md ├── OEM ├── Agent │ └── UPLOAD_SYSTEM_Threshold_UploadMaxDiskUsedPct.md ├── EM_Express │ └── em_express_enable_disable.md └── recreate_dbsnmp_user_and_oem_monitor_role.md ├── Oracle Errors ├── 16047 │ └── ORA-16047_DGID_mismatch_between_dest.md ├── 16525 │ └── ORA-16525_the_data_guard_broker_is_not_yet_available.md ├── 19755 │ └── 19750 │ │ └── 27037 │ │ └── ORA-19755_ORA-19750_ORA-27037.md ├── 19838 │ ├── ORA-19838.md │ └── ORA-19838.txt ├── 20200 │ └── 06512 │ │ └── ORA-20200_ORA-06512_snapshot_id_1_does_not_exist_for_this_database_instance.md ├── 27492 │ └── ORA-27492.md ├── 38784 │ └── ORA-38784_ORA-01153.md ├── 00600 │ ├── 2619 │ │ └── 2103 │ │ │ └── ORA-00600_2619_2103.md │ ├── krccacp_badfile │ │ └── ORA-00600_krccacp_badfile.md │ ├── ksnpostksnigb │ │ └── ORA-00600_ksnpost_ksnigb_ORA-27102.md │ └── qcisSetPlsqlCtxtzi_init │ │ └── ORA-00600_qcisSetPlsqlCtxtzi_init.md ├── 01013 │ └── ORA-01013_ORA-06512_at_line_128.md ├── 01111 │ └── ORA-01111_ORA-01110_ORA-01157_recover_UNNAMED.md ├── 01113 │ ├── ORA-01113_ORA-01110.md │ └── ORA-01113_ORA-01110.txt ├── 01623 │ └── ORA-01623.md ├── 01624 │ └── ORA-01624.md ├── 01652 │ └── ORA-1652_unable_to_extend_temp_segment.md ├── 07445 │ ├── kditpin │ │ ├── ORA-07445_ORA-01652.md │ │ └── ORA-07445_ORA-01652.txt │ ├── kestsaProcOldPlansTopSql │ │ └── ORA-07445_kestsaProcOldPlansTopSql_481.md │ └── ksm_mga_heap_alloc_cbk │ │ └── ORA-07445_ksm_mga_heap_alloc_cbk_166.md ├── 08104 │ └── ORA-08104_this_index_object_is_being_online_built_or_rebuilt.md └── Зависания без ошибок │ └── RMAN │ └── Ресинхронизация RMAN каталога зависает.md ├── Performance Tuning ├── Resource Manager │ ├── resource_manager.md │ └── resource_manager.txt ├── SQL Management │ └── SQL Plan Baselines │ │ ├── copy_plan_from_one_sql_id_to_another.md │ │ └── load_sql_plan_from_awr_into_sql_baseline.md └── SQL Monitoring │ ├── blocking_sessions.md │ └── sql_plan_by_hour.md ├── SQL ├── Hints │ └── DRIVING_SITE.md └── XML │ └── xml_extract_value_from_clob_column.md ├── Stored Procedures ├── C │ └── c_stored_procedure.md └── Java │ ├── getSumDigits.sql │ └── getUniqueCount.sql └── Проведение регламентных работ └── Точки восстановления ├── Удаление точек восстановления └── README.md └── Установка точек восстановления └── README.md /.gitattributes: -------------------------------------------------------------------------------- 1 | # Auto detect text files and perform LF normalization 2 | * text=auto 3 | -------------------------------------------------------------------------------- /Backup and recovery/Corruption/block_recovery_from_standby.md: -------------------------------------------------------------------------------- 1 | # Block recovery from standby 2 | 3 | ## Подготовительные настройки 4 | 5 | Переводим передачу логов в режим LGWR SYNC. 6 | Стендбай открываем в режиме READ ONLY WITH APPLY 7 | 8 | ## Как генерировать ROWID 9 | 10 | Ошибки в V$DATABASE_BLOCK_CORRUPTION 11 | 12 | ```sql 13 | SQL> select * from v$database_block_corruption; 14 | 15 | FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO 16 | ---------- ---------- ---------- ------------------ --------- 17 | 28 4013725 4 2.6362E+10 NOLOGGING 18 | 17 3320404 1 0 FRACTURED 19 | 17 3320405 1 0 ALL ZERO 20 | 17 3320406 1 0 FRACTURED 21 | ``` 22 | 23 | ### Определяем битый объект 24 | 25 | ```sql 26 | select owner, segment_type, segment_name 27 | from dba_extents 28 | where file_id = 17 29 | and 3320406 between block_id and block_id + blocks - 1; 30 | 31 | OWNER SEGMENT_TYPE SEGMENT_NAME 32 | ------------------------------ ------------------ --------------------------------------------------------------------------------- 33 | RSBANK_EVS TABLE DOPRDOCS_DBT 34 | ``` 35 | 36 | ### ID объекта: 37 | 38 | ```sql 39 | SQL> select DATA_OBJECT_ID from dba_objects where OWNER='RSBANK_EVS' and OBJECT_NAME='DOPRDOCS_DBT'; 40 | 41 | DATA_OBJECT_ID 42 | -------------- 43 | 12648237 44 | ``` 45 | 46 | ### Относительный номер файла данных 47 | 48 | ```sql 49 | SQL> select RELATIVE_FNO from dba_data_files where FILE_ID=17; 50 | 51 | RELATIVE_FNO 52 | ------------ 53 | 17 54 | ``` 55 | 56 | ### Генерируем ROWID по полученным данным 57 | 58 | ```sql 59 | set serveroutput on 60 | declare 61 | my_rowid varchar2(30); 62 | begin 63 | DBMS_OUTPUT.ENABLE; 64 | my_rowid := DBMS_ROWID.ROWID_CREATE(1, 12648237, 17, 3320406, 1); 65 | DBMS_OUTPUT.PUT_LINE('ROWID: ' || my_rowid); 66 | end; 67 | / 68 | ``` 69 | 70 | ### Обращаемся к битому блоку по ROWID 71 | 72 | ```sql 73 | SQL> select count(*) from RSBANK_EVS.DOPRDOCS_DBT where rowid='AAwP8tAARAAMqpWAAB'; 74 | select count(*) from RSBANK_EVS.DOPRDOCS_DBT where rowid='AAwP8tAARAAMqpWAAB' 75 | * 76 | ERROR at line 1: 77 | ORA-01578: ORACLE data block corrupted (file # 17, block # 3320406) 78 | ORA-01110: data file 17: '/EV_prim/oradata/users09.dbf' 79 | ``` 80 | 81 | ### После автоматического восстановления блока делаем BACKUP VALIDATE. 82 | 83 | ```sql 84 | RMAN> backup validate check logical datafile 17; 85 | ``` 86 | 87 | # PROFIT!!! 88 | -------------------------------------------------------------------------------- /Backup and recovery/DataGuard Broker/Physical_standby_database_disabled.md: -------------------------------------------------------------------------------- 1 | # DGMGRL: Physical standby database (disabled) 2 | 3 | ## Версии 4 | 5 | ``` 6 | SUSE Linux Enterprise Server 12 (x86_64) 7 | VERSION = 12 8 | PATCHLEVEL = 3 9 | 10 | Oracle 11.2.0.4 11 | ``` 12 | 13 | ## Проблема 14 | 15 | Вывод команды dgmgrl show configuration показывает статус стендбая как disabled при общем статусе SUCCESS 16 | 17 | ``` 18 | DGMGRL> show configuration; 19 | 20 | Configuration - ap_dg_config 21 | 22 | Protection Mode: MaxPerformance 23 | Databases: 24 | prod - Primary database 25 | prod_stb - Physical standby database (disabled) 26 | 27 | Fast-Start Failover: DISABLED 28 | 29 | Configuration Status: 30 | SUCCESS 31 | ``` 32 | 33 | ## Диагностика 34 | 35 | db_unique_name на нодах отличались регистрами. 36 | 37 | ``` 38 | PRD: 39 | 40 | db_unique_name = PROD 41 | log_archive_config = dg_config=(PROD,prod_stb) 42 | 43 | STB: 44 | db_unique_name = prod_stb 45 | log_archive_config = dg_config=(PROD,prod_stb) 46 | ``` 47 | 48 | Конфигурация DataGuard регистрозависимая. Но при создании конфига было указано всё в нижнем регистре. 49 | 50 | ``` 51 | CREATE CONFIGURATION ap_dg_config AS PRIMARY DATABASE IS prod CONNECT IDENTIFIER IS prod_prd; 52 | ``` 53 | 54 | ## Решение 55 | 56 | Конфигурация пересоздана в корректном регистре. 57 | 58 | ``` 59 | REMOVE CONFIGURATION; 60 | CREATE CONFIGURATION ap_dg_config AS PRIMARY DATABASE IS PROD CONNECT IDENTIFIER IS prod_prd; 61 | ADD DATABASE prod_stb AS CONNECT IDENTIFIER IS prod_stb MAINTAINED AS PHYSICAL; 62 | ENABLE CONFIGURATION; 63 | ``` 64 | 65 | -------------------------------------------------------------------------------- /Backup and recovery/Flashback database/Включение Flashback Database/README.md: -------------------------------------------------------------------------------- 1 | # Включение Flashback Database. 2 | 3 | ## Проверяем, включён ли Flashback. 4 | 5 | ```sql 6 | SQL> select flashback_on from v$database; 7 | 8 | FLASHBACK_ON 9 | ------------------ 10 | NO 11 | ``` 12 | 13 | Смотрим, сконфигурирована ли Fast Recovery Area, и достаточно ли в ней места. 14 | 15 | ```sql 16 | SQL> show parameter db_re 17 | 18 | NAME TYPE VALUE 19 | ------------------------------------ ----------- ------------------------------ 20 | db_recovery_file_dest string /u01/oracle/app/fast_recovery_ 21 | area 22 | db_recovery_file_dest_size big integer 35G 23 | ``` 24 | 25 | Проверяем, чем фактически занята Flash Recovery Area 26 | 27 | ```sql 28 | SQL> select * from v$flash_recovery_area_usage; 29 | 30 | FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES 31 | -------------------- ------------------ ------------------------- --------------- 32 | CONTROL FILE 0 0 0 33 | REDO LOG 2 0 8 34 | ARCHIVED LOG 77 77 426 35 | BACKUP PIECE 0 0 0 36 | IMAGE COPY 0 0 0 37 | FLASHBACK LOG 1 0 2 38 | FOREIGN ARCHIVED LOG 0 0 0 39 | ``` 40 | 41 | Проверка, что в разделе достаточно места 42 | 43 | ```bash 44 | df -h /u01/oracle/app/fast_recovery_area 45 | Filesystem Size Used Avail Use% Mounted on 46 | /dev/mapper/data-01 493G 312G 181G 64% /u01 47 | ``` 48 | 49 | Проверяем, что время удержания flashback-логов равно сутки или 1440 минут (по умолчанию). 50 | 51 | ```sql 52 | SQL> show parameter db_flashback_retention_target 53 | 54 | NAME TYPE VALUE 55 | ------------------------------------ ----------- ------------------------------ 56 | db_flashback_retention_target integer 1440 57 | ``` 58 | 59 | Проверяем, включен ли режим Archivelog. 60 | 61 | ```sql 62 | SQL> archive log list 63 | Database log mode Archive Mode 64 | Automatic archival Enabled 65 | Archive destination USE_DB_RECOVERY_FILE_DEST 66 | Oldest online log sequence 7869 67 | Next log sequence to archive 7872 68 | Current log sequence 7872 69 | ``` 70 | 71 | Проверяем, что включена политика удаления архивных логов только после бэкапа на ленту и перименения на стендбае в случае прода. И применении на стендбае в случае стендбая. 72 | 73 | Прод: 74 | ```sql 75 | RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO 'SBT_TAPE'; 76 | ``` 77 | 78 | Стендбай: 79 | ```sql 80 | RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; 81 | ``` 82 | 83 | ## Включение Flashback database. 84 | 85 | На проде: 86 | ```sql 87 | SQL> alter database flashback on; 88 | 89 | Database altered. 90 | ``` 91 | 92 | На стендбае: 93 | 94 | ```sql 95 | SQL> alter database recover managed standby database cancel; 96 | 97 | Database altered. 98 | 99 | SQL> alter database flashback on; 100 | 101 | Database altered. 102 | 103 | SQL> select flashback_on from v$database; 104 | 105 | FLASHBACK_ON 106 | ------------------ 107 | YES 108 | 109 | SQL> alter database recover managed standby database using current logfile disconnect from session; 110 | 111 | Database altered. 112 | ``` -------------------------------------------------------------------------------- /Backup and recovery/Redo/Частота переключения redo.sql: -------------------------------------------------------------------------------- 1 | -- Частота переключения Redo-логов 2 | 3 | SELECT TRUNC (first_time) "дата", 4 | TO_CHAR (first_time, 'Dy', 'NLS_DATE_LANGUAGE = RUSSIAN') "день", 5 | COUNT (1) "общее", 6 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '00', 1, 0)) "час 00", 7 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '01', 1, 0)) "час 01", 8 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '02', 1, 0)) "час 02", 9 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '03', 1, 0)) "час 03", 10 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '04', 1, 0)) "час 04", 11 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '05', 1, 0)) "час 05", 12 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '06', 1, 0)) "час 06", 13 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '07', 1, 0)) "час 07", 14 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '08', 1, 0)) "час 08", 15 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '09', 1, 0)) "час 09", 16 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '10', 1, 0)) "час 10", 17 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '11', 1, 0)) "час 11", 18 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '12', 1, 0)) "час 12", 19 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '13', 1, 0)) "час 13", 20 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '14', 1, 0)) "час 14", 21 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '15', 1, 0)) "час 15", 22 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '16', 1, 0)) "час 16", 23 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '17', 1, 0)) "час 17", 24 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '18', 1, 0)) "час 18", 25 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '19', 1, 0)) "час 19", 26 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '20', 1, 0)) "час 20", 27 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '21', 1, 0)) "час 21", 28 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '22', 1, 0)) "час 22", 29 | SUM (DECODE (TO_CHAR (first_time, 'hh24'), '23', 1, 0)) "час 23", 30 | DECODE ( 31 | TRUNC (first_time), 32 | TRUNC (SYSDATE), ROUND ( 33 | COUNT (1) 34 | / ( 24 35 | * TO_NUMBER (TO_CHAR (SYSDATE, 'sssss') + 1) 36 | / 86400), 37 | 2), 38 | ROUND (COUNT (1) / 24, 2)) 39 | "среднее" 40 | FROM v$log_history 41 | GROUP BY TRUNC (first_time), TO_CHAR (first_time, 'Dy', 'NLS_DATE_LANGUAGE = RUSSIAN') 42 | ORDER BY 1 DESC; -------------------------------------------------------------------------------- /Backup and recovery/Undo/undo_rollback_status.sql: -------------------------------------------------------------------------------- 1 | col "Estimated time to complete" format a40 2 | set linesize 100 3 | alter session set NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'; 4 | select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo", 5 | decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400)) "Estimated time to complete" 6 | from v$fast_start_transactions; -------------------------------------------------------------------------------- /Backup and recovery/Операции с лентой/Dummy SBT tape/README.md: -------------------------------------------------------------------------------- 1 | # Dummy SBT Tape 2 | 3 | В некоторых случаях бывает, что нет возможности подключиться к ленте (её больше нет, БД переехала в изолированный сегмент сети и т.д.), но остаются записи в контрольном файле о бэкапах. Для их удаления необходимо подключить псевдо MML-библиотеку oracle.disksbt. 4 | 5 | ``` 6 | RMAN> allocate channel for maintenance device type sbt parms 'SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)'; 7 | 8 | using target database control file instead of recovery catalog 9 | allocated channel: ORA_MAINT_SBT_TAPE_1 10 | channel ORA_MAINT_SBT_TAPE_1: SID=2278 device type=SBT_TAPE 11 | channel ORA_MAINT_SBT_TAPE_1: WARNING: Oracle Test Disk API 12 | ``` 13 | 14 | Удаляем необходимый бэкапсет. 15 | 16 | ``` 17 | RMAN> delete backupset 73753; 18 | 19 | 20 | List of Backup Pieces 21 | BP Key BS Key Pc# Cp# Status Device Type Piece Name 22 | ------- ------- --- --- ----------- ----------- ---------- 23 | 73761 73753 1 1 UNAVAILABLE SBT_TAPE 9tqlcmvi_1_1 24 | 25 | Do you really want to delete the above objects (enter YES or NO)? yes 26 | deleted backup piece 27 | backup piece handle=9tqlcmvi_1_1 RECID=73761 STAMP=894852082 28 | Deleted 1 objects 29 | ``` 30 | 31 | Его больше нет. 32 | 33 | ``` 34 | RMAN> list backupset 73753; 35 | 36 | RMAN-00571: =========================================================== 37 | RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 38 | RMAN-00571: =========================================================== 39 | RMAN-03002: failure of list command at 09/13/2016 13:25:05 40 | RMAN-20215: backup set not found 41 | RMAN-06159: error while looking up backup set 42 | ``` -------------------------------------------------------------------------------- /Cloud Control/Compliance/Disable_Security_Recommendations_For_Oracle_Products.md: -------------------------------------------------------------------------------- 1 | # Как отключить проверку Security Recommendations For Oracle Products 2 | 3 | ## Проблема 4 | 5 | На главной странице Oracle Enterprise Manager Cloud Control имеется раздел Compliance Summary, в котором имеются оповещения о несоответствии той или иной системы стандартной политике Security Recommendations For Oracle Products 6 | 7 | ## Решение 8 | 9 | 1. Переходим в Enterprise -> Compliance -> Library 10 | 2. Вкладка Compliance Standards 11 | 3. Находим в списке Security Recommendations For Oracle Products 12 | 4. В столбце Association Count жмём на количество 13 | 5. Выбираем нужную цель, и жмём Disable. -------------------------------------------------------------------------------- /Configuration/dblinks/disable_all_dblink_usage.md: -------------------------------------------------------------------------------- 1 | # Как отключить использование DB-линков в БД 2 | 3 | Количество возможные линков контролируется параметрами open_links (на сессию) и open_links_per_instance (на экземпляр), и составляет по умолчанию 4. 4 | 5 | Для отключения необходимо выставить их в 0. Требуется перезагрузка экземпляра. -------------------------------------------------------------------------------- /Configuration/listener/samples/listener.ora: -------------------------------------------------------------------------------- 1 | SID_LIST_LISTENER = 2 | (SID_LIST = 3 | (SID_DESC = 4 | (GLOBAL_DBNAME = lemur_prd_dgmgrl) 5 | (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_1) 6 | (SID_NAME = LEMUR) 7 | (SERVICE_NAME = lemur_prd) 8 | ) 9 | ) 10 | 11 | LISTENER = 12 | (DESCRIPTION_LIST = 13 | (DESCRIPTION = 14 | (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) 15 | ) 16 | (DESCRIPTION = 17 | (ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1521)) 18 | ) 19 | ) 20 | 21 | ADR_BASE_LISTENER = /u01/app/oracle 22 | 23 | -------------------------------------------------------------------------------- /Configuration/listener/samples/tnsnames.ora: -------------------------------------------------------------------------------- 1 | LEMUR = 2 | (DESCRIPTION = 3 | (ADDRESS = (PROTOCOL = TCP)(HOST = srv-dbastudy-ora01)(PORT = 1521)) 4 | (CONNECT_DATA = 5 | (SID = LEMUR) 6 | ) 7 | ) 8 | 9 | LEMUR_PRD = 10 | (DESCRIPTION = 11 | (ADDRESS = (PROTOCOL = TCP)(HOST = srv-dbastudy-ora01)(PORT = 1521)) 12 | (CONNECT_DATA = 13 | (SERVICE_NAME = lemur_prd) 14 | ) 15 | ) 16 | -------------------------------------------------------------------------------- /DataPump/Export/sample_schema_export.par: -------------------------------------------------------------------------------- 1 | USERID='/ as sysdba' 2 | directory=DUMP 3 | schemas=SCHEMA_NAME 4 | flashback_time=systimestamp 5 | logfile=exp_SCHEMA_NAME.log 6 | dumpfile=exp_SCHEMA_NAME_%U.dump 7 | PARALLEL=4 8 | REUSE_DUMPFILES=Y 9 | COMPRESSION=ALL -------------------------------------------------------------------------------- /DataPump/Import/sample_schema_import.par: -------------------------------------------------------------------------------- 1 | USERID='/ as sysdba' 2 | DIRECTORY=DUMP 3 | logfile=import_SAMPLE_SCHEMA.log 4 | dumpfile=exp_SAMPLE_SCHEMA_%U.dump 5 | schemas=SAMPLE_SCHEMA 6 | PARALLEL=4 7 | TRANSFORM=SEGMENT_ATTRIBUTES:n 8 | REMAP_TABLESPACE=TBS1:USERS 9 | REMAP_TABLESPACE=TBS2:USERS 10 | -------------------------------------------------------------------------------- /Events/acknowledge over PGA limit/acknowledge over PGA limit.md: -------------------------------------------------------------------------------- 1 | # acknowledge over PGA limit 2 | 3 | ## Версия 4 | 5 | 12.2.0.1.0 6 | SUSE Linux Enterprise Server 12 (x86_64) 7 | VERSION = 12 8 | PATCHLEVEL = 3 9 | 10 | ## Изменения 11 | 12 | Проблема обнаружена после увеличения памяти сервера с 4 до 16 ГБ, и перенастройки экземпляра на использование новых значений. 13 | 14 | ## Диагностика 15 | 16 | Имеются высокие ожидания acknowledge over PGA limit (до 50% от активных сессий). 17 | acknowledge over PGA limit - это новое событие ожидание, введённое с появлением параметра PGA_AGGREGATE_LIMIT в 12.1 18 | Вероятно, это BUG 26255710 - "ACKNOWLEDGE OVER PGA LIMIT" AFFECTS THE PERFORMANCE OF PL/SQL PROGRAM 19 | 20 | ## Решение: 21 | 22 | 1. Отключить параметр PGA_AGGREGATE_LIMIT 23 | ``` 24 | alter system set PGA_AGGREGATE_LIMIT=0 scope=both; 25 | ``` 26 | 27 | или 28 | 29 | 2. Установить Patch 24416451 -------------------------------------------------------------------------------- /Events/enq JI - contention/enq JI - contention.md: -------------------------------------------------------------------------------- 1 | # enq: JI - contention 2 | 3 | ## Версия 4 | 5 | ``` 6 | 11.2.0.4.0 7 | SUSE Linux Enterprise Server 12 (x86_64) 8 | VERSION = 12 9 | PATCHLEVEL = 3 10 | ``` 11 | 12 | ## Изменения 13 | 14 | Ранее были созданы материализованные представления (materialized view) 15 | 16 | ## Диагностика 17 | 18 | В БД постоянно наблюдаются ожидания enq: JI - contention 19 | В топе по данным ожиданиям несколько запросов, связанных с обновлением материализованных представлений в режиме DEMAND. 20 | 21 | 22 | ## Решение: 23 | 24 | Откат и переработка работы с материализованными представлениями. -------------------------------------------------------------------------------- /Events/enq SQ - contention/enq SQ - contention.md: -------------------------------------------------------------------------------- 1 | # enq: SQ - contention 2 | 3 | ## Версия 4 | 5 | ``` 6 | 11.2.0.4.0 7 | SUSE Linux Enterprise Server 12 (x86_64) 8 | VERSION = 12 9 | PATCHLEVEL = 3 10 | ``` 11 | 12 | ## Изменения 13 | 14 | Нет 15 | 16 | ## Диагностика 17 | 18 | В БД периодически наблюдаются всплески ожиданий enq: SQ - contention 19 | В топе по данным ожиданиям несколько запросов. 20 | 21 | ```sql 22 | SELECT 23 | sql_id, 24 | COUNT(*) 25 | FROM 26 | v$active_session_history 27 | WHERE 28 | event = 'enq: SQ - contention' 29 | GROUP BY 30 | sql_id 31 | ORDER BY 2 DESC; 32 | ``` 33 | 34 | Смотрим текст запроса, и последовательности (sequence), которые в них используются. 35 | 36 | ``` 37 | SELECT * FROM TABLE(dbms_xplan.display_cursor('0g5w81yq3b22f')); 38 | ``` 39 | 40 | Смотрим, каков размер кэша у последовательности. 41 | 42 | ```sql 43 | SELECT 44 | sequence_owner, 45 | sequence_name, 46 | cache_size 47 | FROM 48 | dba_sequences 49 | WHERE 50 | sequence_owner = 'TEST' 51 | AND sequence_name = 'SEQ_RN'; 52 | ``` 53 | 54 | ## Решение: 55 | 56 | Увеличиваем размер кэша последовательности. 57 | 58 | ``` 59 | alter sequence TEST.SEQ_RN cache 1000; 60 | ``` -------------------------------------------------------------------------------- /Events/errorstack/errorstack_trace_enable.md: -------------------------------------------------------------------------------- 1 | # Включение errorstack-трассировки на уровне БД 2 | 3 | ``` 4 | alter system set events '1013 trace name errorstack level 3'; 5 | ``` 6 | 7 | Выключить можно, поставив уровень 0. 8 | 9 | ``` 10 | alter system set events '1013 trace name errorstack level 0'; 11 | ``` -------------------------------------------------------------------------------- /Events/event 10261.md: -------------------------------------------------------------------------------- 1 | # Ограничение потребления PGA сессиями 2 | 3 | Событие 10261 позволяет ограничить потребление PGA сессиями. Его удобно использовать, когда из-за кривого кода часто происходят утечки памяти. 4 | 5 | ## Установим эвент: 6 | 7 | > Не разрешим сессии использовать более 200 Мб (Параметр эвента - килобайты) 8 | 9 | ```sql 10 | ALTER SYSTEM SET event = '10261 trace name context forever, level 204800' SCOPE=SPFILE; 11 | ``` 12 | 13 | > Обязательно перезапустим базу 14 | 15 | ```sql 16 | SHUTDOWN ABORT; 17 | STARTUP; 18 | ``` 19 | 20 | 21 | 22 | Теперь при потреблении памяти сессиями более 200 Мб в alert log посыпятся ошибки вида: 23 | 24 | ``` 25 | Tue Mar 11 10:31:10 2010 26 | Errors in file /oracle/coredump/testdb_ora_1704.trc: 27 | ORA-00600: internal error code, arguments: [723], [12628], [pga heap], [], [], [], [], [] 28 | ``` 29 | 30 | Автору кода нужно указать на утечку памяти. 31 | -------------------------------------------------------------------------------- /Events/events_set_in_session.sql: -------------------------------------------------------------------------------- 1 | -- Нужны права на SYS.DBMS_SYSTEM 2 | set serveroutput on 3 | declare 4 | event_level number; 5 | counter number; 6 | begin 7 | dbms_output.enable; 8 | counter := 0; 9 | for i in 10000 .. 10999 loop 10 | sys.dbms_system.read_ev(i, event_level); -- начиная с Oracle 11g показывает только цифровые события, соответствующие кодам ORA-10NNN 11 | if (event_level > 0) then 12 | dbms_output.put_line('Event ' || to_char(i) || ' set at level ' || to_char(event_level)); 13 | counter := counter + 1; 14 | end if; 15 | end loop; 16 | if (counter = 0) then 17 | dbms_output.put_line('No events set for this session'); 18 | end if; 19 | end; 20 | / -------------------------------------------------------------------------------- /Events/oradebug/show_events_set_in_another_session.md: -------------------------------------------------------------------------------- 1 | # Определение, какие события (events) установлены в другой сессии 2 | 3 | 4 | ## Пример 5 | 6 | 1. В первой сессии ставим sql_trace 7 | ``` 8 | ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'; 9 | ``` 10 | 11 | 2. В другой сессии определяем её pid 12 | ``` 13 | select p.pid 14 | from v$process p, v$session s 15 | where p.addr = s.paddr 16 | and s.username = 'YOUR_USER'; 17 | ``` 18 | 19 | 3. В sqlplus запускаем oradebug и получаем результат 20 | ``` 21 | SQL> oradebug setorapid 112 22 | Oracle pid: 112, Unix process pid: 26139, image: oracle@srv-cls-ora01 23 | SQL> oradebug eventdump session 24 | sql_trace level=8 25 | ``` -------------------------------------------------------------------------------- /Installation/Problems/INS-30131.md: -------------------------------------------------------------------------------- 1 | # INS-30131 initial setup required for the execution of installer validations failed 2 | 3 | ## Проблема 4 | 5 | При установке 11.2.0.4 на SUSE Linux Enterprise Server 12 (проблеме подвержены и другие Linux-дистрибутивы) 6 | 7 | ``` 8 | INS-30131 initial setup required for the execution of installer validations failed 9 | Action - ensure that the current user has required permissions to access the temporary location 10 | ``` 11 | 12 | ## Диагостика 13 | 14 | Права на /tmp у oracle есть. Файлы и папки создаются. 15 | Место в разделе есть. 16 | Машина была клонирована, и остался "мусор" с прошлых инсталляций. 17 | 18 | ## Решение 19 | 20 | Очистка /tmp 21 | Перезагрузка сервера -------------------------------------------------------------------------------- /Installation/Problems/error_invoking_target_agent_nmhs_of_makefile.md: -------------------------------------------------------------------------------- 1 | # Error in invoking target 'agent nmhs' of makefile 2 | 3 | ## Проблема 4 | 5 | При установке 11.2.0.4 на SUSE Linux Enterprise Server 12 (проблеме подвержены и другие Linux-дистрибутивы) 6 | 7 | ``` 8 | Error in invoking target 'agent nmhs' of makefile '/u01/app/oracle/product/11.2.0.4/dbhome_1/sysman/lib/ins_emagent.mk'. See '/u01/app/oraInventory/logs/installActions2019-05-27_04-07-11PM.log' for details. 9 | ``` 10 | 11 | ## Решение 12 | 13 | Необходимо отредактировать следующий файл: 14 | 15 | ``` 16 | $ORACLE_HOME/sysman/lib/ins_emagent.mk 17 | ``` 18 | 19 | Находим следующую строку, и добавляем опцию "-lnnz11" 20 | 21 | Меняем: 22 | ``` 23 | $(MK_EMAGENT_NMECTL) 24 | ``` 25 | на 26 | ``` 27 | $(MK_EMAGENT_NMECTL) -lnnz11 28 | ``` 29 | 30 | Жмём Retry. -------------------------------------------------------------------------------- /Installation/Problems/recreate_orainventory.md: -------------------------------------------------------------------------------- 1 | # Пересоздание orainventory 2 | 3 | ## Проблема 4 | 5 | По каким-либо причинам побилось/удалилось инвентори 6 | 7 | ## Решение 8 | 9 | > Можно делать в онлайне 10 | 11 | 1. Создать новую папку /opt/oraInventory с правами 755 и oracle:oinstall 12 | 2. В /etc/oraInst.loc прописать путь к ней. 13 | 3. Выставляем окружение под нужный хомяк через oraenv или по другому 14 | 4. Аттачим Oracle Home 15 | ``` 16 | cd $ORACLE_HOME/oui/bin 17 | ./runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/opt/oracle/product/db_19" ORACLE_HOME_NAME="Oracle19c_home" 18 | ``` 19 | 20 | Шаги 3-4 повторить для каждого хомяка -------------------------------------------------------------------------------- /Listener/TNS-/TNS-01189_The listener could not authenticate the user.md: -------------------------------------------------------------------------------- 1 | # TNS-01189: The listener could not authenticate the user 2 | 3 | ## Проблема 4 | 5 | В мониторинге OEM получаем слудующую ошибку: 6 | ``` 7 | TNS-1189. Please check log for details. 8 | ``` 9 | 10 | В логе лисенера на соответствующем сервере наблюдаем следующее. 11 | ``` 12 | Tue Oct 08 16:41:37 2019 13 | 08-OCT-2019 16:41:37 * (CONNECT_DATA=(COMMAND=version)) * version * 1189 14 | TNS-01189: The listener could not authenticate the user 15 | ``` 16 | 17 | ## Диагностика 18 | 19 | Данных в логе недостаточно. Непонятно, откуда приходит запрос. 20 | Необходимо включить трассировку лисенера. 21 | 22 | ``` 23 | lsnrctl 24 | 25 | LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 11-OCT-2019 00:11:03 26 | 27 | Copyright (c) 1991, 2013, Oracle. All rights reserved. 28 | 29 | Welcome to LSNRCTL, type "help" for information. 30 | 31 | LSNRCTL> help trace 32 | trace OFF | USER | ADMIN | SUPPORT [] : set tracing to the specified level 33 | 34 | LSNRCTL> trace support <<<<<<<<<<<<<<<< Включение трассировки 35 | Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) 36 | Opened trace file: /oracle/diag/tnslsnr/o7/listener/trace/ora_27745_140057668736832.trc <<<<<<<<< файл трассировки Listener 37 | The command completed successfully 38 | LSNRCTL> trace off <<<<<<<<<<<<<<<< Отключение трассировки 39 | Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) 40 | The command completed successfully 41 | LSNRCTL> exit 42 | ``` 43 | 44 | В папке, где находится listener.log, будет создан дополнительно трейс с расширенной иноформацией. 45 | 46 | 47 | ## Решение 48 | 49 | Ошибка разовая. Так и не удалось воспроизвести для детального анализа. -------------------------------------------------------------------------------- /OEM/Agent/UPLOAD_SYSTEM_Threshold_UploadMaxDiskUsedPct.md: -------------------------------------------------------------------------------- 1 | # UPLOAD SYSTEM Threshold (UploadMaxDiskUsedPct: 98) exceeded with 98.00839) 2 | 3 | ## Проблема 4 | 5 | Получаем сообщения в OEM о том, что закончилось место на Upload System. 6 | 7 | emctl status agent 8 | 9 | ``` 10 | Oracle Enterprise Manager Cloud Control 12c Release 4 11 | Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. 12 | --------------------------------------------------------------- 13 | Agent Version : 12.1.0.4.0 14 | OMS Version : 12.1.0.4.0 15 | Protocol Version : 12.1.0.1.0 16 | ... 17 | Number of XML files pending upload : 0 18 | Size of XML files pending upload(MB) : 0 19 | Available disk space on upload filesystem : 1,36% 20 | Collection Status : [COLLECTIONS_HALTED( 21 | UPLOAD SYSTEM Threshold (UploadMaxDiskUsedPct: 98) exceeded with 98.00839)] 22 | Heartbeat Status : Ok 23 | ... 24 | ``` 25 | 26 | Данная ошибка является предупреждение о превышении порога по месту, но не на OMS, а на самом таргете. Конфигурируется параметром агента UploadMaxDiskUsedPct 27 | 28 | ## Решение 29 | 30 | ``` 31 | emctl setproperty agent -name UploadMaxDiskUsedPct -value 99 32 | Oracle Enterprise Manager Cloud Control 12c Release 4 33 | Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. 34 | EMD setproperty succeeded 35 | 36 | emctl stop agent 37 | emctl start agent 38 | ``` 39 | 40 | После перезагрузки агент перестаёт ругаться. -------------------------------------------------------------------------------- /OEM/EM_Express/em_express_enable_disable.md: -------------------------------------------------------------------------------- 1 | # Как включить и выключить EM Express 12c 2 | 3 | ## Проверить статус EM Express 4 | 5 | ``` 6 | select dbms_xdb.getHttpPort() from dual; 7 | select dbms_xdb_config.getHttpsPort() from dual; 8 | ``` 9 | 10 | ## Включить EM Express через HTTPS 11 | 12 | ``` 13 | exec dbms_xdb_config.sethttpsport(5500); 14 | ``` 15 | 16 | ## Включить EM Express через HTTP 17 | 18 | ``` 19 | exec dbms_xdb_config.sethttpport(8080); 20 | ``` 21 | 22 | ## Отключение EM Express 23 | 24 | Для отключения выставляем значение в 0. 25 | 26 | ``` 27 | exec dbms_xdb_config.sethttpsport(0); 28 | exec dbms_xdb_config.sethttpport(0); 29 | ``` -------------------------------------------------------------------------------- /OEM/recreate_dbsnmp_user_and_oem_monitor_role.md: -------------------------------------------------------------------------------- 1 | # Пересоздание пользователя DBSNMP и роли OEM_MONITOR 2 | 3 | ## Проблема 4 | 5 | Отсутствует пользователь DBSNMP в БД. Нет возможности добавить БД в мониторинг Cloud Control. 6 | 7 | # Решение 8 | 9 | Подключение / as sysdba 10 | 11 | Удаление всего сущенствующего, что относится к данной схеме, если есть хвосты. 12 | 13 | ``` 14 | SQL> @?/rdbms/admin/catnsnmp.sql 15 | ``` 16 | 17 | Создание пользователя DBSNMP и роли OEM_MONITOR 18 | 19 | ``` 20 | SQL> @?/rdbms/admin/catsnmp.sql 21 | ``` 22 | 23 | Установка пароля для пользователя. 24 | ``` 25 | SQL> alter user dbsnmp identified by account unlock; 26 | ``` -------------------------------------------------------------------------------- /Oracle Errors/00600/2619/2103/ORA-00600_2619_2103.md: -------------------------------------------------------------------------------- 1 | # ORA-00600: internal error code, arguments: [2619], [2103], [], [], [], [], [], [], [], [], [], [] 2 | 3 | ## Проблема. 4 | 5 | На стендбай-сервере в алерт-логе имеем следующие ошибки. 6 | 7 | ``` 8 | Media Recovery Log /u01/app/oracle/fast_recovery_area/SKUUK2_STB/archivelog/2019_07_20/o1_mf_1_2103_gm537j05_.arc 9 | Errors in file /u01/app/oracle/diag/rdbms/skuuk2_stb/SKUUK2/trace/SKUUK2_pr00_28248.trc (incident=160422): 10 | ORA-00600: internal error code, arguments: [2619], [2103], [], [], [], [], [], [], [], [], [], [] 11 | Incident details in: /u01/app/oracle/diag/rdbms/skuuk2_stb/SKUUK2/incident/incdir_160422/SKUUK2_pr00_28248_i160422.trc 12 | ``` 13 | 14 | ## Диагностика. 15 | 16 | Трейсы не информативны. 17 | 18 | 19 | 20 | ## Решение. 21 | 22 | Это баг. Данное поведение описано в DBMS Scheduler Jobs Does not run Automatically and Manual run Errors out With ORA-27492 (Doc ID 1590864.1) 23 | 24 | Была предпринята неудачная попытка перезапуска экземпляра. Когда вызывается shutdown, Oracle дизейблит шедулер, но по ряду причин процесс шатдауна был отменён. Это оставило шедулер в неконсистентном состоянии, что привело к невозможности запуска джобов. 25 | 26 | Корректная перезагрузка экземпляра решает проблему. 27 | 28 | ``` 29 | SQL> SHUTDOWN IMMEDIATE; 30 | SQL> STARTUP; 31 | ``` -------------------------------------------------------------------------------- /Oracle Errors/00600/krccacp_badfile/ORA-00600_krccacp_badfile.md: -------------------------------------------------------------------------------- 1 | # Ошибки ORA-00600: internal error code, arguments: [krccacp_badfile], [10150310067047], [10150310065594], [], [], [], [], [], [], [], [], [] 2 | 3 | ## Версия 4 | 5 | 11.2.0.4.0 6 | SUSE Linux Enterprise Server 12 (x86_64) 7 | VERSION = 12 8 | PATCHLEVEL = 3 9 | 10 | ## Изменения 11 | 12 | БД является новой копией БД, находящейся на том же сервере. Сам запустился нормально, но при запуске изсходного экземпляра упал с ошибкой: 13 | 14 | ``` 15 | Errors in file /u01/app/oracle/diag/rdbms/stndcopy/STNDCOPY/trace/STNDCOPY_ctwr_31324.trc (incident=36153): 16 | ORA-00600: internal error code, arguments: [krccacp_badfile], [10150310067047], [10150310065594], [], [], [], [], [], [], [], [], [] 17 | Incident details in: /u01/app/oracle/diag/rdbms/stndcopy/STNDCOPY/incident/incdir_36153/STNDCOPY_ctwr_31324_i36153.trc 18 | ``` 19 | 20 | 21 | ## Диагностика 22 | 23 | Из инцидент-трейса видно, что экземпляр упал из-за проблем у процесса CTWR (Change Tracking Writer), который отвечает за работу block change tracking файла. 24 | 25 | ``` 26 | ... 27 | Instance name: STNDCOPY 28 | Redo thread mounted by this instance: 1 29 | Oracle process number: 19 30 | Unix process pid: 31324, image: oracle@srv-test-ora05 (CTWR) 31 | ... 32 | 33 | Dump continued from file: /u01/app/oracle/diag/rdbms/stndcopy/STNDCOPY/trace/STNDCOPY_ctwr_31324.trc 34 | ORA-00600: internal error code, arguments: [krccacp_badfile], [10150310067047], [10150310065594], [], [], [], [], [], [], [], [], [] 35 | ... 36 | ``` 37 | 38 | 39 | ## Решение: 40 | 41 | Забыл переименовать или отключить Block Change Tracking файл в скопированной БД. Произошёл конфликт процессов CTWR. 42 | Отключение Block Change Tracking. 43 | 44 | ``` 45 | SQL> startup mount; 46 | 47 | SQL> select filename from v$block_change_tracking; 48 | 49 | SQL> alter database disable block change tracking; 50 | 51 | Database altered. 52 | 53 | SQL> select status from v$block_change_tracking; 54 | 55 | STATUS 56 | ------------------------------ 57 | DISABLED 58 | 59 | ``` 60 | 61 | -------------------------------------------------------------------------------- /Oracle Errors/00600/ksnpostksnigb/ORA-00600_ksnpost_ksnigb_ORA-27102.md: -------------------------------------------------------------------------------- 1 | # ORA-00600: internal error code, arguments: [ksnpost:ksnigb], [], [], [], [], [], [], [], [], [], [], [] 2 | 3 | ## Проблема. 4 | 5 | В alert-логе наблюдаем следующие ошибки: 6 | 7 | ``` 8 | Errors in file /opt/oracle/diag/rdbms/orcl_prd_new/orcl/trace/orcl_ora_1317.trc (incident=161942): 9 | ORA-00600: internal error code, arguments: [ksnpost:ksnigb], [], [], [], [], [], [], [], [], [], [], [] 10 | ORA-27102: out of memory 11 | Linux-x86_64 Error: 12: Cannot allocate memory 12 | Additional information: 108 13 | Additional information: 3342336 14 | ``` 15 | 16 | ## Диагностика. 17 | 18 | В трейсе /opt/oracle/diag/rdbms/orcl_prd_new/orcl/trace/orcl_ora_1317.trc: 19 | 20 | ``` 21 | ... 22 | *** 2019-07-26 10:38:05.266 23 | *** SESSION ID:(4983.27015) 2019-07-26 10:38:05.266 24 | *** CLIENT ID:() 2019-07-26 10:38:05.266 25 | *** SERVICE NAME:(orcl) 2019-07-26 10:38:05.266 26 | *** MODULE NAME:(SOME$BudgSomeBalance) 2019-07-26 10:38:05.266 27 | *** ACTION NAME:(Execute) 2019-07-26 10:38:05.266 28 | 29 | mmap(offset=240381952, len=8192) failed with errno=12 for the file oracleORCL 30 | mmap(offset=240381952, len=8192) failed with errno=12 for the file oracleORCL 31 | mmap(offset=240381952, len=8192) failed with errno=12 for the file oracleORCL 32 | mmap(offset=240381952, len=8192) failed with errno=12 for the file oracleORCL 33 | mmap(offset=240381952, len=8192) failed with errno=12 for the file oracleORCL 34 | ... 35 | ``` 36 | 37 | Видим, что есть проблемы с выделением памяти. 38 | Смотрим текущее потребление. 39 | 40 | ``` 41 | SELECT 42 | s.sid, 43 | s.username, 44 | s.program, 45 | s.sql_id, 46 | s.prev_sql_id, 47 | s.module, 48 | s.machine, 49 | s.event, 50 | p.pga_used_mem 51 | FROM 52 | v$session s 53 | JOIN v$process p ON s.paddr = p.addr 54 | ORDER BY 55 | p.pga_used_mem DESC; 56 | ``` 57 | 58 | Смотрим размер pga_aggregate_target. 59 | ``` 60 | select name,value from v$parameter where name = 'pga_aggregate_target'; 61 | ``` 62 | 63 | В ОС смотрим текущее потребление. Видим, что скушался своп. 64 | ``` 65 | top - 11:24:09 up 181 days, 13:52, 4 users, load average: 17.38, 16.51, 16.63 66 | Tasks: 2609 total, 20 running, 2589 sleeping, 0 stopped, 0 zombie 67 | %Cpu(s): 40.1 us, 8.7 sy, 0.0 ni, 42.4 id, 8.4 wa, 0.0 hi, 0.5 si, 0.0 st 68 | KiB Mem: 13192270+total, 13143004+used, 492656 free, 9268 buffers 69 | KiB Swap: 22495228 total, 21795368 used, 699860 free. 4127684 cached Mem 70 | ... 71 | ``` 72 | 73 | 74 | ## Решение. 75 | 76 | Данные анализа направлены ответственным лицам. Запущена бизнес-задача. Мониторят. -------------------------------------------------------------------------------- /Oracle Errors/00600/qcisSetPlsqlCtxtzi_init/ORA-00600_qcisSetPlsqlCtxtzi_init.md: -------------------------------------------------------------------------------- 1 | # Ошибки ORA-00600: internal error code, arguments: [qcisSetPlsqlCtx:tzi init] 2 | 3 | ## Версия 4 | 5 | 11.2.0.4.0 6 | SUSE Linux Enterprise Server 12 (x86_64) 7 | VERSION = 12 8 | PATCHLEVEL = 3 9 | 10 | ## Изменения 11 | 12 | Создание тестовой копии для продуктивной БД в отдельном контуре. Новая установка. Те же патчи. 13 | 14 | ``` 15 | ORA-00600: internal error code, arguments: [qcisSetPlsqlCtx:tzi init], [], [], [], [], [], [], [], [], [], [], [] 16 | ``` 17 | 18 | 19 | ## Диагностика 20 | 21 | Патчи на проде и тесте совпадают 22 | 23 | ``` 24 | 31219953;OJVM PATCH SET UPDATE 11.2.0.4.200714 25 | 31103343;Database Patch Set Update : 11.2.0.4.200714 (31103343) 26 | 27015449; 27 | ``` 28 | 29 | Но при запросе к v$timezone_file на тесет пусто: 30 | 31 | ``` 32 | SQL> SELECT version FROM v$timezone_file; 33 | 34 | no rows selected 35 | 36 | SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value 37 | FROM DATABASE_PROPERTIES 38 | WHERE PROPERTY_NAME LIKE 'DST_%' 39 | ORDER BY PROPERTY_NAME; 2 3 4 40 | 41 | PROPERTY_NAME 42 | -------------------------------------------------------------------------------- 43 | VALUE 44 | -------------------------------------------------------------------------------- 45 | DST_PRIMARY_TT_VERSION 46 | 25 47 | 48 | DST_SECONDARY_TT_VERSION 49 | 0 50 | 51 | DST_UPGRADE_STATE 52 | NONE 53 | ``` 54 | 55 | На проде: 56 | 57 | ``` 58 | SQL> SELECT version FROM v$timezone_file; 59 | 60 | VERSION 61 | ---------- 62 | 25 63 | 64 | SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value 65 | FROM DATABASE_PROPERTIES 66 | WHERE PROPERTY_NAME LIKE 'DST_%' 67 | ORDER BY PROPERTY_NAME; 2 3 4 68 | 69 | PROPERTY_NAME 70 | -------------------------------------------------------------------------------- 71 | VALUE 72 | -------------------------------------------------------------------------------- 73 | DST_PRIMARY_TT_VERSION 74 | 25 75 | 76 | DST_SECONDARY_TT_VERSION 77 | 0 78 | 79 | DST_UPGRADE_STATE 80 | NONE 81 | 82 | ``` 83 | 84 | 85 | При проверке выяснилось, что в $ORACLE_HOME/oracore/zoneinfo разный набор патчей. На тесте отсутствует 25 версия файла. Хотя патч установлен для 31 версии. 86 | 87 | ## Решение: 88 | 89 | Как оказалось, DST-патчи не куммулятивные. Ставится конкретная версия. На проде была промежуточная 25, а затем поставили 31. Но в БД не меняли. Там так и осталась 25. 90 | 91 | Варианты решения: 92 | 1. Обновить на тесте в БД версию до 31, для которой есть патч 93 | 2. Если обновление не подходит по тем или иным причинам, то просто скопировать содержимое директории $ORACLE_HOME/oracore/zoneinfo с прода на тест. -------------------------------------------------------------------------------- /Oracle Errors/01013/ORA-01013_ORA-06512_at_line_128.md: -------------------------------------------------------------------------------- 1 | # ORA-01013: user requested cancel of current operation ORA-06512: at line 128 в мониторинге Cloud Control 13c 2 | 3 | ## Проблема 4 | 5 | В мониторинг OEM 13c, периодически падают сообщения вида: 6 | 7 | ``` 8 | CRITICAL: ORCL2 - ORA-01013: user requested cancel of current operation ORA-06512: at line 128 9 | 10 | Host name: srv-ORCL2p1-ora01.mosgorzdrav.local 11 | 12 | Timestamp: 2019-03-04 16:12:40 13 | ``` 14 | 15 | ## Диагностика 16 | 17 | Получает их Emagent. Диагностируем следующим образом. 18 | По умолчанию ошибки ORA-01013 в alert log не попадают. Включаем errorstack trace на это событие. 19 | 20 | ```sql 21 | alter system set events '1013 trace name errorstack level 3'; 22 | ``` 23 | 24 | Через некоторое время в логе появится сообщение вида: 25 | 26 | ``` 27 | Mon Mar 04 16:12:34 2019 28 | 29 | Errors in file /u01/app/oracle/diag/rdbms/ORCL2/ORCL2/trace/ORCL2_ora_19021.trc: 30 | 31 | ORA-01013: user requested cancel of current operation 32 | ``` 33 | 34 | В трейсе находим следующее: 35 | 36 | 37 | ``` 38 | *** 2019-03-04 16:12:34.026 39 | *** SESSION ID:(580.5) 2019-03-04 16:12:34.026 40 | *** CLIENT ID:() 2019-03-04 16:12:34.026 41 | *** SERVICE NAME:(SYS$USERS) 2019-03-04 16:12:34.026 42 | *** MODULE NAME:(emagent_SQL_oracle_database) 2019-03-04 16:12:34.026 43 | *** ACTION NAME:(ha_backup_sbt) 2019-03-04 16:12:34.026 44 | 45 | dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0) 46 | 47 | ----- Error Stack Dump ----- 48 | ORA-01013: user requested cancel of current operation 49 | ----- Current SQL Statement for this session (sql_id=dx4nqvbtu06bx) ----- 50 | SELECT MEDIA FROM V$BACKUP_PIECE_DETAILS WHERE SESSION_KEY=:B3 AND SESSION_RECID=:B2 AND SESSION_STAMP=:B1 AND DEVICE_TYPE = 'SBT_TAPE' AND ROWNUM = 1 51 | ``` 52 | 53 | Ошибка от EmAgent. Это бага. Лечится сбором статистики по словарю и системным табличным пространствам. 54 | 55 | 56 | ## Решение 57 | 58 | ```sql 59 | exec dbms_stats.gather_fixed_objects_stats; 60 | exec dbms_stats.gather_schema_stats ('SYSTEM'); 61 | exec dbms_stats.gather_schema_stats ('SYS'); 62 | exec dbms_stats.gather_dictionary_stats; 63 | alter system flush shared_pool; 64 | alter system flush shared_pool; 65 | alter system flush shared_pool; 66 | ``` -------------------------------------------------------------------------------- /Oracle Errors/01111/ORA-01111_ORA-01110_ORA-01157_recover_UNNAMED.md: -------------------------------------------------------------------------------- 1 | # ORA-01111: name for data file 62 is unknown - rename to correct file 2 | 3 | ## Проблема 4 | 5 | ```sql 6 | ORA-01111: name for data file 62 is unknown - rename to correct file 7 | ORA-01110: data file 62: '/opt/oracle/product/11.2.0.3/dbhome_1/dbs/UNNAMED00062' 8 | ORA-01157: cannot identify/lock data file 62 - see DBWR trace file 9 | ``` 10 | 11 | После добавления файла данных на проде, он не создан на стендбае. 12 | Это происходит, когда пути на проде нет соответствующего пути на стендбае. 13 | 14 | ## Решение 15 | 16 | Файла не существует. Необходимо его досоздать. 17 | 18 | ```sql 19 | SQL> ALTER DATABASE CREATE DATAFILE '/opt/oracle/product/11.2.0.3/dbhome_1/dbs/UNNAMED00062' as '/u02/oracle/prod/owfin_d/owfin_d04.dbf'; 20 | 21 | Database altered. 22 | 23 | SQL> !ls -la /u02/oracle/prod/owfin_d/owfin_d04.dbf 24 | -rw-r----- 1 oracle oinstall 628717312 Aug 16 17:05 /u02/oracle/prod/owfin_d/owfin_d04.dbf 25 | 26 | SQL> alter database recover managed standby database using current logfile disconnect from session; 27 | 28 | Database altered. 29 | ``` -------------------------------------------------------------------------------- /Oracle Errors/01113/ORA-01113_ORA-01110.md: -------------------------------------------------------------------------------- 1 | # ORA-01113: file 1 needs media recovery при том, что файлы консистентны. 2 | 3 | ## Проблема 4 | 5 | ```sql 6 | SQL> alter database open resetlogs; 7 | alter database open resetlogs 8 | * 9 | ERROR at line 1: 10 | ORA-01113: file 1 needs media recovery 11 | ORA-01110: data file 1: '+DATA/test/datafile/system.3526.1005658309' 12 | ``` 13 | 14 | При этом видим, что файлы консистентны. Должно открыться. 15 | 16 | ```sql 17 | SQL> select CHECKPOINT_CHANGE#,count(*) from v$datafile_header group by CHECKPOINT_CHANGE#; 18 | 19 | CHECKPOINT_CHANGE# COUNT(*) 20 | ------------------ ------------------ 21 | 10158822344122 40 22 | ``` 23 | 24 | ## Решение 25 | 26 | Ходил вокруг, да около. Сломал голову. Пробовал AUTO. Не сработало. В общем, надо отмемить процесс восстановления. 27 | 28 | ```sql 29 | SQL> recover using backup controlfile until cancel; 30 | ORA-00279: change 10158822344122 generated at 04/15/2019 16:56:14 needed for thread 1 31 | ORA-00289: suggestion : +DATA 32 | ORA-00280: change 10158822344122 for thread 1 is in sequence #96945 33 | 34 | 35 | Specify log: {=suggested | filename | AUTO | CANCEL} 36 | cancel 37 | Media recovery cancelled. 38 | 39 | SQL> alter database open resetlogs; 40 | 41 | Database altered. 42 | ``` -------------------------------------------------------------------------------- /Oracle Errors/01113/ORA-01113_ORA-01110.txt: -------------------------------------------------------------------------------- 1 | ORA-01113: file 1 needs media recovery при том, что файлы консистентны. 2 | 3 | Проблема 4 | 5 | SQL> alter database open resetlogs; 6 | alter database open resetlogs 7 | * 8 | ERROR at line 1: 9 | ORA-01113: file 1 needs media recovery 10 | ORA-01110: data file 1: '+DATA/test/datafile/system.3526.1005658309' 11 | 12 | При этом видим, что файлы консистентны. Должно открыться. 13 | 14 | SQL> select CHECKPOINT_CHANGE#,count(*) from v$datafile_header group by CHECKPOINT_CHANGE#; 15 | 16 | CHECKPOINT_CHANGE# COUNT(*) 17 | ------------------ ------------------ 18 | 10158822344122 40 19 | 20 | 21 | Решение 22 | 23 | Ходил вокруг, да около. Сломал голову. Пробовал AUTO. Не сработало. В общем, надо отмемить процесс восстановления. 24 | 25 | 26 | SQL> recover using backup controlfile until cancel; 27 | ORA-00279: change 10158822344122 generated at 04/15/2019 16:56:14 needed for thread 1 28 | ORA-00289: suggestion : +DATA 29 | ORA-00280: change 10158822344122 for thread 1 is in sequence #96945 30 | 31 | 32 | Specify log: {=suggested | filename | AUTO | CANCEL} 33 | cancel 34 | Media recovery cancelled. 35 | 36 | SQL> alter database open resetlogs; 37 | 38 | Database altered. 39 | -------------------------------------------------------------------------------- /Oracle Errors/01623/ORA-01623.md: -------------------------------------------------------------------------------- 1 | # ORA-01623: log 5 is current log for instance ORCL (thread 1) - cannot drop 2 | 3 | ## Проблема 4 | 5 | На физическом стендбае при попытке удаления лога возникают следующие ошибки, когда редо-лог в статусе CURRENT. 6 | 7 | ``` 8 | SQL> alter database drop logfile group 5; 9 | alter database drop logfile group 5 10 | * 11 | ERROR at line 1: 12 | ORA-01623: log 5 is current log for instance ORCL (thread 1) - cannot drop 13 | ORA-00312: online log 5 thread 1: '/u01/app/oracle/oradata/ORCL_STB/onlinelog/o1_mf_5_g685y1m9_.log' 14 | ORA-00312: online log 5 thread 1: '/u01/app/oracle/fast_recovery_area/ORCL_STB/onlinelog/o1_mf_5_g685y1wk_.log' 15 | ``` 16 | 17 | ## Решение 18 | 19 | К сожалению, несмотря на то, что до перевода БД в Read Write редо-логи никак не используются, Oracle не предоставляет каких-либо механизмов, позволяющих их удалить или хотя бы переключить. 20 | Для выхода из положения необходимо как-то переключить лог, либо пересоздать контрольный файл. Второй вариант как-то не очень, так что будем переключать. 21 | 22 | 1. Переводим БД в режим SNAPSHOT STANDBY. 23 | 24 | ``` 25 | SHUTDOWN IMMEDIATE; 26 | STARTUP MOUNT; 27 | ``` 28 | 29 | 2. Убедиться, что процесс наката остановлен. 30 | 31 | ``` 32 | ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 33 | ``` 34 | 35 | 3. Перевести БД в режим SNAPSHOT STANDBY. 36 | 37 | ``` 38 | SELECT flashback_on FROM v$database; 39 | 40 | FLASHBACK_ON 41 | ------------------ 42 | NO 43 | 44 | ALTER DATABASE CONVERT TO SNAPSHOT STANDBY; 45 | ALTER DATABASE OPEN; 46 | SELECT flashback_on FROM v$database; 47 | 48 | FLASHBACK_ON 49 | ------------------ 50 | RESTORE POINT ONLY 51 | ``` 52 | 53 | 4. Теперь, когда БД открыта в режиме READ WRITE, мы можем переключить злосчастный лог. 54 | 55 | ``` 56 | alter system switch logfile; 57 | ``` 58 | 59 | 5. Возвращаем БД в режим физического стендбая. 60 | 61 | ``` 62 | SHUTDOWN IMMEDIATE; 63 | STARTUP MOUNT; 64 | ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 65 | SHUTDOWN IMMEDIATE; 66 | STARTUP NOMOUNT; 67 | ALTER DATABASE MOUNT STANDBY DATABASE; 68 | ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 69 | SELECT flashback_on FROM v$database; 70 | 71 | FLASHBACK_ON 72 | ------------------ 73 | NO 74 | ``` 75 | 76 | Теперь, когда лог не в статусе CURRENT, можно очистить и удалить его. 77 | 78 | ``` 79 | SQL> alter database clear logfile group 5; 80 | 81 | Database altered. 82 | 83 | 84 | SQL> alter database drop logfile group 5; 85 | 86 | Database altered. 87 | ``` -------------------------------------------------------------------------------- /Oracle Errors/01624/ORA-01624.md: -------------------------------------------------------------------------------- 1 | # ORA-01624: log 1 needed for crash recovery of instance ORCL (thread 1) 2 | 3 | ## Проблема 4 | 5 | На физическом стендбае при попытке удаления онлайн-лога в статусах отличных от CURRENT можем получить слудующие ошибки. 6 | 7 | ``` 8 | SQL> alter database drop logfile group 1; 9 | alter database drop logfile group 1 10 | * 11 | ERROR at line 1: 12 | ORA-01624: log 1 needed for crash recovery of instance ORCL (thread 1) 13 | ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/ORCL_STB/onlinelog/o1_mf_1_g68599s1_.log' 14 | ORA-00312: online log 1 thread 1: '/u01/app/oracle/fast_recovery_area/ORCL_STB/onlinelog/o1_mf_1_g6859b69_.log' 15 | ``` 16 | 17 | ## Решение 18 | 19 | Необходимо очистить лог перед удалением. 20 | 21 | ``` 22 | SQL> alter database clear logfile group 1; 23 | 24 | Database altered. 25 | ``` 26 | 27 | > Процедура сработает только для файлов, которые в статусах не равных CURRENT. CURRENT при дропе выдаст ORA-01623: log 5 is current log for instance ORCL (thread 1) - cannot drop 28 | 29 | Далее удаляем лог. 30 | 31 | ``` 32 | SQL> alter database drop logfile group 1; 33 | 34 | Database altered. 35 | ``` -------------------------------------------------------------------------------- /Oracle Errors/01652/ORA-1652_unable_to_extend_temp_segment.md: -------------------------------------------------------------------------------- 1 | # ORA-1652: unable to extend temp segment by 128 in tablespace TEMP 2 | 3 | ## Версия 4 | 5 | 11.2.0.4.0 6 | SUSE Linux Enterprise Server 12 (x86_64) 7 | VERSION = 12 8 | PATCHLEVEL = 3 9 | 10 | ## Проблема 11 | 12 | В алерт-логе БД имеются ошибки вида: 13 | ``` 14 | Tue Aug 13 09:58:45 2019 15 | ORA-1652: unable to extend temp segment by 128 in tablespace TEMP 16 | ``` 17 | 18 | ## Диагностика 19 | 20 | Если случай единичный, как правило, можно просто игнорировать. 21 | Для порядка можно проверить размер TEMP. Может, он действительно мал. 22 | 23 | ``` 24 | select sum(bytes)/1024/1024/1024 "SIZE_GB" from dba_temp_files where tablespace_name = 'TEMP'; 25 | ``` 26 | 27 | На всякий случай можно включить трассировку errorstack по событию 1652. Тогда при следующей подобной ошибке мы получим подробный трейс с кодом проблемного запроса. 28 | 29 | ``` 30 | alter system set events '1652 trace name errorstack level 3'; 31 | ``` 32 | 33 | ## Решение 34 | 35 | После генерации errorstack trace выявить проблемный запрос, и оптимизировать его. -------------------------------------------------------------------------------- /Oracle Errors/07445/kditpin/ORA-07445_ORA-01652.md: -------------------------------------------------------------------------------- 1 | # Ошибки ORA-07445 [kditpin()+54], ORA-01652 2 | 3 | ## Диагностика 4 | 5 | В алерт-логе БД имеем: 6 | 7 | ``` 8 | Thu Apr 11 07:27:57 2019 9 | ORA-1652: unable to extend temp segment by 128 in tablespace TEMP 10 | Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x1996340, kditpin()+54] [flags: 0x0, count: 1] 11 | Errors in file /u01/app/oracle/diag/rdbms/drweb/DRWEB/trace/DRWEB_ora_32564.trc (incident=39514): 12 | ORA-07445: exception encountered: core dump [kditpin()+54] [SIGSEGV] [ADDR:0x0] [PC:0x1996340] [Address not mapped to object] [] 13 | ORA-01652: unable to extend temp segment by 128 in tablespace TEMP 14 | Incident details in: /u01/app/oracle/diag/rdbms/drweb/DRWEB/incident/incdir_39514/DRWEB_ora_32564_i39514.trc 15 | ``` 16 | 17 | В /u01/app/oracle/diag/rdbms/drweb/DRWEB/incident/incdir_39514/DRWEB_ora_32564_i39514.trc: 18 | 19 | ``` 20 | ... 21 | Dump continued from file: /u01/app/oracle/diag/rdbms/drweb/DRWEB/trace/DRWEB_ora_32564.trc 22 | ORA-07445: exception encountered: core dump [kditpin()+54] [SIGSEGV] [ADDR:0x0] [PC:0x1996340] [Address not mapped to object] [] 23 | ORA-01652: unable to extend temp segment by 128 in tablespace TEMP 24 | 25 | ========= Dump for incident 39514 (ORA 7445 [kditpin()+54]) ======== 26 | ----- Beginning of Customized Incident Dump(s) ----- 27 | Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x1996340, kditpin()+54] [flags: 0x0, count: 1] 28 | Registers: 29 | %rax: 0x0000000000000000 %rbx: 0x000000000c12e220 %rcx: 0x0000000000000002 30 | %rdx: 0x0000000000000000 %rdi: 0x000000000c12e220 %rsi: 0x00007f71cfaa5b20 31 | %rsp: 0x00007fff0ee83b80 %rbp: 0x00007fff0ee83cb0 %r8: 0x000000000a164788 32 | %r9: 0x00007f71cfc55c70 %r10: 0x00007f71cfc547b8 %r11: 0x0000000000000070 33 | %r12: 0x0000000000001fe8 %r13: 0x000000000c12e220 %r14: 0x00007f71cfaa5b20 34 | %r15: 0x00007fff0ee83cc0 %rip: 0x0000000001996340 %efl: 0x0000000000010202 35 | kditpin()+40 (0x1996332) movzwl 0x1a(%r14),%r12d 36 | kditpin()+45 (0x1996337) mov 0x24(%r14),%ecx 37 | kditpin()+49 (0x199633b) and $2,%ecx 38 | kditpin()+52 (0x199633e) je 0x199636b 39 | > kditpin()+54 (0x1996340) movzbl (%rdx),%eax 40 | kditpin()+57 (0x1996343) cmp $1,%eax 41 | kditpin()+60 (0x1996346) jne 0x199636b 42 | kditpin()+62 (0x1996348) add $1,%rdx 43 | kditpin()+66 (0x199634c) mov (%rdx),%rax 44 | 45 | *** 2019-04-11 07:27:58.861 46 | dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0) 47 | ----- Current SQL Statement for this session (sql_id=bmfmcnf831qyc) ----- 48 | SELECT * FROM admin_activity 49 | 50 | ----- Call Stack Trace ----- 51 | calling call entry argument values in hex 52 | location type point (? means dubious value) 53 | -------------------- -------- -------------------- ---------------------------- 54 | skdstdst()+41 call kgdsdst() 000000000 ? 000000000 ? 55 | 7F71CFD9FDC0 ? 7F71CFD9FE98 ? 56 | 7F71CFDA4940 ? 000000003 ? 57 | ksedst1()+103 call skdstdst() 000000000 ? 000000000 ? 58 | 7F71CFD9FDC0 ? 7F71CFD9FE98 ? 59 | 7F71CFDA4940 ? 000000003 ? 60 | ksedst()+39 call ksedst1() 000000001 ? 000000001 ? 61 | 7F71CFD9FDC0 ? 7F71CFD9FE98 ? 62 | 7F71CFDA4940 ? 000000003 ? 63 | ... 64 | ``` 65 | 66 | 67 | Нас здесь интересуют аргументы **kditpin()+54**. Их можно вводить в соотвествующее поле поиска в *ORA-600/ORA-7445/ORA-700 Error Look-up Tool (Doc ID 153788.1)* 68 | Находим, что это баг *Bug 9756271 - Dump on kditpin (Doc ID 9756271.8)* 69 | Исправлен в *11.2.0.4.4 (Oct 2014) Database Patch Set Update (DB PSU)* 70 | 71 | В этой БД, как оказалось, не стоит никакой PSU. 72 | 73 | ```bash 74 | > $ORACLE_HOME/OPatch/opatch lsinventory 75 | Oracle Interim Patch Installer version 11.2.0.3.4 76 | Copyright (c) 2012, Oracle Corporation. All rights reserved. 77 | 78 | 79 | Oracle Home : /u01/app/oracle/product/11.2.0/dbhome_1 80 | Central Inventory : /u01/app/oraInventory 81 | from : /u01/app/oracle/product/11.2.0/dbhome_1/oraInst.loc 82 | OPatch version : 11.2.0.3.4 83 | OUI version : 11.2.0.4.0 84 | Log file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2019-04-11_16-50-38PM_1.log 85 | 86 | Lsinventory Output file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/lsinv/lsinventory2019-04-11_16-50-38PM.txt 87 | 88 | -------------------------------------------------------------------------------- 89 | Installed Top-level Products (1): 90 | 91 | Oracle Database 11g 11.2.0.4.0 92 | There are 1 products installed in this Oracle Home. 93 | 94 | 95 | There are no Interim patches installed in this Oracle Home. 96 | 97 | 98 | -------------------------------------------------------------------------------- 99 | 100 | OPatch succeeded. 101 | ``` 102 | 103 | ## Решение: 104 | 105 | Поставить *11.2.0.4.4 (Oct 2014) Database Patch Set Update (DB PSU)* и выше для исправления *Bug 9756271 - Dump on kditpin (Doc ID 9756271.8)* 106 | 107 | 108 | ## Ради интереса: 109 | 110 | Изучаем трейс. Сбой произошёл в данной строке кода: 111 | 112 | ``` 113 | > kditpin()+54 (0x1996340) movzbl (%rdx),%eax 114 | ``` 115 | 116 | Здесь происходит копирование значения, которое находится по адресу, хранимом в регистре **%rdx** в регистр **%eax**. Однако, в регистре **%rdx** хранится адрес *0x0000000000000000*. Нужный адрес никто в него ранее не внёс. 117 | Получаем ошибку о недопустимой адрессации от операционной системы. 118 | 119 | ``` 120 | SIGSEGV, Address not mapped to object 121 | ``` 122 | -------------------------------------------------------------------------------- /Oracle Errors/07445/kditpin/ORA-07445_ORA-01652.txt: -------------------------------------------------------------------------------- 1 | В алерт-логе БД имеем: 2 | 3 | Thu Apr 11 07:27:57 2019 4 | ORA-1652: unable to extend temp segment by 128 in tablespace TEMP 5 | Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x1996340, kditpin()+54] [flags: 0x0, count: 1] 6 | Errors in file /u01/app/oracle/diag/rdbms/drweb/DRWEB/trace/DRWEB_ora_32564.trc (incident=39514): 7 | ORA-07445: exception encountered: core dump [kditpin()+54] [SIGSEGV] [ADDR:0x0] [PC:0x1996340] [Address not mapped to object] [] 8 | ORA-01652: unable to extend temp segment by 128 in tablespace TEMP 9 | Incident details in: /u01/app/oracle/diag/rdbms/drweb/DRWEB/incident/incdir_39514/DRWEB_ora_32564_i39514.trc 10 | 11 | В /u01/app/oracle/diag/rdbms/drweb/DRWEB/incident/incdir_39514/DRWEB_ora_32564_i39514.trc: 12 | 13 | ... 14 | Dump continued from file: /u01/app/oracle/diag/rdbms/drweb/DRWEB/trace/DRWEB_ora_32564.trc 15 | ORA-07445: exception encountered: core dump [kditpin()+54] [SIGSEGV] [ADDR:0x0] [PC:0x1996340] [Address not mapped to object] [] 16 | ORA-01652: unable to extend temp segment by 128 in tablespace TEMP 17 | 18 | ========= Dump for incident 39514 (ORA 7445 [kditpin()+54]) ======== 19 | ----- Beginning of Customized Incident Dump(s) ----- 20 | Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x1996340, kditpin()+54] [flags: 0x0, count: 1] 21 | Registers: 22 | %rax: 0x0000000000000000 %rbx: 0x000000000c12e220 %rcx: 0x0000000000000002 23 | %rdx: 0x0000000000000000 %rdi: 0x000000000c12e220 %rsi: 0x00007f71cfaa5b20 24 | %rsp: 0x00007fff0ee83b80 %rbp: 0x00007fff0ee83cb0 %r8: 0x000000000a164788 25 | %r9: 0x00007f71cfc55c70 %r10: 0x00007f71cfc547b8 %r11: 0x0000000000000070 26 | %r12: 0x0000000000001fe8 %r13: 0x000000000c12e220 %r14: 0x00007f71cfaa5b20 27 | %r15: 0x00007fff0ee83cc0 %rip: 0x0000000001996340 %efl: 0x0000000000010202 28 | kditpin()+40 (0x1996332) movzwl 0x1a(%r14),%r12d 29 | kditpin()+45 (0x1996337) mov 0x24(%r14),%ecx 30 | kditpin()+49 (0x199633b) and $2,%ecx 31 | kditpin()+52 (0x199633e) je 0x199636b 32 | > kditpin()+54 (0x1996340) movzbl (%rdx),%eax 33 | kditpin()+57 (0x1996343) cmp $1,%eax 34 | kditpin()+60 (0x1996346) jne 0x199636b 35 | kditpin()+62 (0x1996348) add $1,%rdx 36 | kditpin()+66 (0x199634c) mov (%rdx),%rax 37 | 38 | *** 2019-04-11 07:27:58.861 39 | dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0) 40 | ----- Current SQL Statement for this session (sql_id=bmfmcnf831qyc) ----- 41 | SELECT * FROM admin_activity 42 | 43 | ----- Call Stack Trace ----- 44 | calling call entry argument values in hex 45 | location type point (? means dubious value) 46 | -------------------- -------- -------------------- ---------------------------- 47 | skdstdst()+41 call kgdsdst() 000000000 ? 000000000 ? 48 | 7F71CFD9FDC0 ? 7F71CFD9FE98 ? 49 | 7F71CFDA4940 ? 000000003 ? 50 | ksedst1()+103 call skdstdst() 000000000 ? 000000000 ? 51 | 7F71CFD9FDC0 ? 7F71CFD9FE98 ? 52 | 7F71CFDA4940 ? 000000003 ? 53 | ksedst()+39 call ksedst1() 000000001 ? 000000001 ? 54 | 7F71CFD9FDC0 ? 7F71CFD9FE98 ? 55 | 7F71CFDA4940 ? 000000003 ? 56 | ... 57 | 58 | 59 | Нас здесь интересуют аргументы kditpin()+54. Их можно вводить в соотвествующее поле поиска в ORA-600/ORA-7445/ORA-700 Error Look-up Tool (Doc ID 153788.1) 60 | Находим, что это баг Bug 9756271 - Dump on kditpin (Doc ID 9756271.8) 61 | Исправлен в 11.2.0.4.4 (Oct 2014) Database Patch Set Update (DB PSU) 62 | 63 | В этой БД, как оказалось, не стоит никакой PSU. 64 | 65 | > $ORACLE_HOME/OPatch/opatch lsinventory 66 | Oracle Interim Patch Installer version 11.2.0.3.4 67 | Copyright (c) 2012, Oracle Corporation. All rights reserved. 68 | 69 | 70 | Oracle Home : /u01/app/oracle/product/11.2.0/dbhome_1 71 | Central Inventory : /u01/app/oraInventory 72 | from : /u01/app/oracle/product/11.2.0/dbhome_1/oraInst.loc 73 | OPatch version : 11.2.0.3.4 74 | OUI version : 11.2.0.4.0 75 | Log file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2019-04-11_16-50-38PM_1.log 76 | 77 | Lsinventory Output file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/lsinv/lsinventory2019-04-11_16-50-38PM.txt 78 | 79 | -------------------------------------------------------------------------------- 80 | Installed Top-level Products (1): 81 | 82 | Oracle Database 11g 11.2.0.4.0 83 | There are 1 products installed in this Oracle Home. 84 | 85 | 86 | There are no Interim patches installed in this Oracle Home. 87 | 88 | 89 | -------------------------------------------------------------------------------- 90 | 91 | OPatch succeeded. 92 | 93 | 94 | Решение: 95 | 96 | Поставить 11.2.0.4.4 (Oct 2014) Database Patch Set Update (DB PSU) и выше для исправления Bug 9756271 - Dump on kditpin (Doc ID 9756271.8) 97 | 98 | 99 | Ради интереса: 100 | 101 | Изучаем трейс. Сбой произошёл в данной строке кода: 102 | 103 | > kditpin()+54 (0x1996340) movzbl (%rdx),%eax 104 | 105 | 106 | Здесь происходит копирование значения, которое находится по адресу, хранимом в регистре %rdx в регистр %eax. Однако, в регистре %rdx хранится адрес 0x0000000000000000. Нужный адрес никто в него ранее не внёс. 107 | Получаем ошибку о недопустимой адрессации от операционной системы. 108 | 109 | SIGSEGV, Address not mapped to object 110 | -------------------------------------------------------------------------------- /Oracle Errors/07445/kestsaProcOldPlansTopSql/ORA-07445_kestsaProcOldPlansTopSql_481.md: -------------------------------------------------------------------------------- 1 | # Ошибки ORA-07445: exception encountered: core dump [kestsaProcOldPlansTopSql()+481] [SIGSEGV] [ADDR:0x0] [PC:0x9879F21] [Address not mapped to object] [] 2 | 3 | > !!!! Описанное ниже не помогло !!!! 4 | 5 | ## Версия 6 | 7 | ``` 8 | 19.4.0.0.0 9 | SUSE Linux Enterprise Server 12 (x86_64) 10 | VERSION = 12 11 | PATCHLEVEL = 3 12 | ``` 13 | 14 | ## Изменения 15 | 16 | Проблема обнаружена после апгрейда БД с 18 до 19 версии. 17 | 18 | ## Диагностика 19 | 20 | В алерт-логе БД имеем: 21 | 22 | ``` 23 | 2019-09-29T22:04:52.957867+03:00 24 | Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x9879F21, kestsaProcOldPlansTopSql()+481] [flags: 0x0, count: 1] 25 | Errors in file /u01/oracle/app/diag/rdbms/oemdb/OEMDB/trace/OEMDB_j004_2268.trc (incident=245683) (PDBNAME=CDB$ROOT): 26 | ORA-07445: exception encountered: core dump [kestsaProcOldPlansTopSql()+481] [SIGSEGV] [ADDR:0x0] [PC:0x9879F21] [Address not mapped to object] [] 27 | Incident details in: /u01/oracle/app/diag/rdbms/oemdb/OEMDB/incident/incdir_245683/OEMDB_j004_2268_i245683.trc 28 | ``` 29 | 30 | В /u01/oracle/app/diag/rdbms/oemdb/OEMDB/incident/incdir_245683/OEMDB_j004_2268_i245683.trc: 31 | 32 | ``` 33 | ... 34 | *** 2019-09-29T22:04:53.184000+03:00 35 | *** SESSION ID:(2298.63646) 2019-09-29T22:04:53.184030+03:00 36 | *** CLIENT ID:() 2019-09-29T22:04:53.184038+03:00 37 | *** SERVICE NAME:(SYS$USERS) 2019-09-29T22:04:53.184046+03:00 38 | *** MODULE NAME:(DBMS_SCHEDULER) 2019-09-29T22:04:53.184053+03:00 39 | *** ACTION NAME:(ORA$AT_SQ_SQL_SW_32182) 2019-09-29T22:04:53.184060+03:00 40 | *** CLIENT DRIVER:() 2019-09-29T22:04:53.184068+03:00 41 | *** CONTAINER ID:(1) 2019-09-29T22:04:53.184075+03:00 42 | 43 | [TOC00000] 44 | Jump to table of contents 45 | Dump continued from file: /u01/oracle/app/diag/rdbms/oemdb/OEMDB/trace/OEMDB_j004_2268.trc 46 | [TOC00001] 47 | ORA-07445: exception encountered: core dump [kestsaProcOldPlansTopSql()+481] [SIGSEGV] [ADDR:0x0] [PC:0x9879F21] [Address not mapped to object] [] 48 | 49 | [TOC00001-END] 50 | 51 | [TOC00002] 52 | ========= Dump for incident 245683 (ORA 7445 [kestsaProcOldPlansTopSql]) ======== 53 | [TOC00003] 54 | ----- Beginning of Customized Incident Dump(s) ----- 55 | Dumping swap information 56 | Memory (Avail / Total) = 214.50M / 24003.48M 57 | Swap (Avail / Total) = 14884.68M / 16384.00M 58 | Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x9879F21, kestsaProcOldPlansTopSql()+481] [flags: 0x0, count: 1] 59 | Registers: 60 | %rax: 0x0000000000000000 %rbx: 0x00007fff9295a960 %rcx: 0x000000000000f89e 61 | %rdx: 0x0000000000000009 %rdi: 0x00007fff9295c8e0 %rsi: 0x00007fff92958798 62 | %rsp: 0x00007fff92958080 %rbp: 0x00007fff929582c0 %r8: 0x0000000000000000 63 | %r9: 0x00007fff929581e8 %r10: 0x00007fff92958b88 %r11: 0x000236b49017e06c 64 | %r12: 0x00007fff9295ce00 %r13: 0x00007fff92958798 %r14: 0x0000000000000000 65 | %r15: 0x00007fff9295c8e0 %rip: 0x0000000009879f21 %efl: 0x0000000000010203 66 | kestsaProcOldPlansTopSql()+466 (0x9879f12) mov 0x18(%rbp),%r10 67 | kestsaProcOldPlansTopSql()+470 (0x9879f16) mov %r15,%rdi 68 | kestsaProcOldPlansTopSql()+473 (0x9879f19) mov %r13,%rsi 69 | kestsaProcOldPlansTopSql()+476 (0x9879f1c) mov $0x9,%edx 70 | > kestsaProcOldPlansTopSql()+481 (0x9879f21) mov (%rax),%r11 71 | kestsaProcOldPlansTopSql()+484 (0x9879f24) lea -0x38(%rbp),%r9 72 | kestsaProcOldPlansTopSql()+488 (0x9879f28) mov 0x34(%r12),%ecx 73 | kestsaProcOldPlansTopSql()+493 (0x9879f2d) mov %r10,(%rsp) 74 | kestsaProcOldPlansTopSql()+497 (0x9879f31) mov 0x108(%r11),%r8 75 | 76 | *** 2019-09-29T22:04:53.203663+03:00 77 | dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0) 78 | [TOC00004] 79 | ----- Current SQL Statement for this session (sql_id=4xm1ruvkx3awx) ----- 80 | DECLARE job BINARY_INTEGER := :job; next_date TIMESTAMP WITH TIME ZONE := :mydate; broken BOOLEAN := FALSE; job_name VARCHAR2(128) := :job_name; job_subname VARCHAR2(128) := :job_subname; job_owner VARCHAR2(128) := :job_owner; job_start TIMESTAMP WITH TIME ZONE := :job_start; job_scheduled_start TIMESTAMP WITH TIME ZONE := :job_scheduled_start; window_start TIMESTAMP WITH TIME ZONE := :window_start; window_end TIMESTAMP WITH TIME ZONE := :window_end; chain_id VARCHAR2(14) := :chainid; credential_owner VARCHAR2(128) := :credown; credential_name VARCHAR2(128) := :crednam; destination_owner VARCHAR2(128) := :destown; destination_name VARCHAR2(128) := :destnam; job_dest_id varchar2(14) := :jdestid; log_id number := :log_id; BEGIN DECLARE 81 | ename VARCHAR2(30); 82 | exec_task BOOLEAN; 83 | BEGIN 84 | -- check if tuning pack is enabled 85 | exec_task := prvt_advisor.is_pack_enabled( 86 | dbms_management_packs.TUNING_PACK); 87 | -- check if we are in a pdb, 88 | -- since auto sqltune is not run in a pdb 89 | IF (exec_task AND -- tuning pack enabled 90 | sys_context('userenv', 'con_id') <> 0 AND -- not in non-cdb 91 | sys_context('userenv', 'con_id') <> 1 ) THEN -- not in root 92 | exec_task := FALSE; 93 | END IF; 94 | -- execute auto sql tuning task 95 | IF (exec_task) THEN 96 | ename := dbms_sqltune.execute_tuning_task( 97 | 'SYS_AUTO_SQL_TUNING_TASK'); 98 | END IF; 99 | -- check whether we are in non-CDB or a PDB 100 | -- auto SPM evolve only runs in a non-CDB or a PDB, not the root. 101 | IF (sys_context('userenv', 'con_id') = 0 OR 102 | sys_context('userenv', 'con_id') > 2) THEN 103 | exec_task := TRUE; 104 | ELSE 105 | exec_task := FALSE; 106 | END IF; 107 | -- execute auto SPM evolve task 108 | IF (exec_task) THEN 109 | ename := dbms_spm.execute_evolve_task('SYS_AUTO_SPM_EVOLVE_TASK'); 110 | END IF; 111 | END; :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END; 112 | [TOC00005] 113 | ----- PL/SQL Stack ----- 114 | ----- PL/SQL Call Stack ----- 115 | object line object 116 | handle number name 117 | 0x6b3e91f8 14140 package body SYS.DBMS_SQLTUNE_INTERNAL.I_SUB_EXECUTE_CALLOUT 118 | 0x6b3e91f8 14167 package body SYS.DBMS_SQLTUNE_INTERNAL.I_SUB_EXECUTE 119 | 0xc4d572e0 8 type body SYS.WRI$_ADV_SQLTUNE.SUB_EXECUTE 120 | 0x7136fdd8 915 package body SYS.PRVT_ADVISOR.COMMON_SUB_EXECUTE 121 | 0x7136fdd8 3451 package body SYS.PRVT_ADVISOR.COMMON_EXECUTE_TASK 122 | 0x6b44bb38 276 package body SYS.DBMS_ADVISOR.EXECUTE_TASK 123 | 0x6b3b22e8 1217 package body SYS.DBMS_SQLTUNE.EXECUTE_TUNING_TASK 124 | 0xcec99b50 19 anonymous block 125 | [TOC00005-END] 126 | [TOC00004-END] 127 | ... 128 | ``` 129 | 130 | Ошибка не информативна. 131 | ``` 132 | > kestsaProcOldPlansTopSql()+481 (0x9879f21) mov (%rax),%r11 133 | ``` 134 | 135 | Произошло обращение к области памяти, расположенной по адресу, который прописан в регистре RAX. При этом в регистре RAX нули. 136 | ``` 137 | %rax: 0x0000000000000000 138 | ``` 139 | 140 | Вызвало "Address not mapped to object". 141 | 142 | Видно, что выполняются регламентные внутренние процедуры DBMS_SQLTUNE, DBMS_ADVISOR. Насколько я понимаю, это всё часть джобов ADDM. Ошибки возникают раз в четыре часа. 143 | 144 | ## Решение: 145 | 146 | Не уверен, что все из указанных действий необходимы, но что-то из этого решило проблему. 147 | 148 | 1. Согласно How To Reload the SYS.DBMS_STATS Package (Doc ID 1310365.1) перестроил пакет SYS.DBMS_STATS 149 | 150 | Советую сразу записать инвалиды, если есть. У меня по нулям. 151 | 152 | ``` 153 | select object_name from dba_objects where status='INVALID'; 154 | ``` 155 | 156 | Перестраиваем пакет SYS.DBMS_STATS 157 | 158 | ``` 159 | @?/rdbms/admin/dbmsstat.sql 160 | @?/rdbms/admin/prvtstas.plb 161 | @?/rdbms/admin/prvtstai.plb 162 | @?/rdbms/admin/prvtstat.plb 163 | ``` 164 | 165 | Не забываем перестроить инвалидные объекты. Их много. 166 | 167 | ``` 168 | select object_name from dba_objects where status='INVALID'; 169 | 170 | @?/rdbms/admin/utlrp.sql 171 | ``` 172 | 173 | 2. Перестраиваем системную статистику. 174 | 175 | ``` 176 | exec dbms_stats.gather_fixed_objects_stats; 177 | exec dbms_stats.gather_schema_stats ('SYS'); 178 | exec dbms_stats.gather_schema_stats ('SYSTEM'); 179 | exec dbms_stats.gather_dictionary_stats; 180 | 181 | alter system flush shared_pool; 182 | alter system flush shared_pool; 183 | alter system flush shared_pool; 184 | ``` 185 | 186 | Больше проблема не повторяется. 187 | -------------------------------------------------------------------------------- /Oracle Errors/07445/ksm_mga_heap_alloc_cbk/ORA-07445_ksm_mga_heap_alloc_cbk_166.md: -------------------------------------------------------------------------------- 1 | # Ошибки ORA-07445: exception encountered: core dump [ksm_mga_heap_alloc_cbk()+166] [SIGBUS] [ADDR:0x40000A000000] [PC:0xFC5B36] [Non-existent physical address] [] 2 | 3 | ## Версия 4 | 5 | 12.2.0.1.0 6 | SUSE Linux Enterprise Server 12 (x86_64) 7 | VERSION = 12 8 | PATCHLEVEL = 3 9 | 10 | ## Изменения 11 | 12 | Проблема обнаружена после увеличения памяти сервера с 4 до 16 ГБ, и перенастройки экземпляра на использование новых значений. 13 | 14 | ## Диагностика 15 | 16 | В алерт-логе БД имеем: 17 | 18 | ``` 19 | 2019-08-08T00:58:03.057831+03:00 20 | Exception [type: SIGBUS, Non-existent physical address] [ADDR:0x40000A000000] [PC:0xFC5B36, ksm_mga_heap_alloc_cbk()+166] [flags: 0x0, count: 1] 21 | Errors in file /u01/app/oracle/diag/rdbms/gdes/GDES/trace/GDES_m000_7901.trc (incident=65811) (PDBNAME=CDB$ROOT): 22 | ORA-07445: exception encountered: core dump [ksm_mga_heap_alloc_cbk()+166] [SIGBUS] [ADDR:0x40000A000000] [PC:0xFC5B36] [Non-existent physical address] [] 23 | ``` 24 | 25 | В /u01/app/oracle/diag/rdbms/gdes/GDES/trace/GDES_m000_7901.trc: 26 | 27 | ``` 28 | ... 29 | *** 2019-08-08T00:58:03.057619+03:00 (CDB$ROOT(1)) 30 | *** SESSION ID:(15.23571) 2019-08-08T00:58:03.057661+03:00 31 | *** CLIENT ID:() 2019-08-08T00:58:03.057667+03:00 32 | *** SERVICE NAME:(SYS$BACKGROUND) 2019-08-08T00:58:03.057674+03:00 33 | *** MODULE NAME:(MMON_SLAVE) 2019-08-08T00:58:03.057680+03:00 34 | *** ACTION NAME:(Automatic Report Flush) 2019-08-08T00:58:03.057686+03:00 35 | *** CLIENT DRIVER:() 2019-08-08T00:58:03.057692+03:00 36 | *** CONTAINER ID:(1) 2019-08-08T00:58:03.057699+03:00 37 | 38 | Exception [type: SIGBUS, Non-existent physical address] [ADDR:0x40000A000000] [PC:0xFC5B36, ksm_mga_heap_alloc_cbk()+166] [flags: 0x0, count: 1] 39 | DDE: Problem Key 'ORA 7445 [ksm_mga_heap_alloc_cbk]' was flood controlled (0x2) (incident: 65811) 40 | ORA-07445: exception encountered: core dump [ksm_mga_heap_alloc_cbk()+166] [SIGBUS] [ADDR:0x40000A000000] [PC:0xFC5B36] [Non-existent physical address] [] 41 | Dumping swap information 42 | Memory (Avail / Total) = 4317.56M / 16046.42M 43 | Swap (Avail / Total) = 1332.00M / 1332.00M 44 | ssexhd: crashing the process... 45 | Shadow_Core_Dump = partial 46 | ksdbgcra: writing core file to directory '/u01/app/oracle/diag/rdbms/gdes/GDES/cdump' 47 | 48 | ... 49 | ``` 50 | 51 | Нас в данном трейсе интересует только шапка. 52 | MODULE NAME:(MMON_SLAVE) 53 | ACTION NAME:(Automatic Report Flush) 54 | 55 | Видно, что проблема возникает лишь в работе процесса MMON и, собственно, его слейвов M000 и т.д., которые падают... 56 | Падает на процессе Automatic Report Flush. Это часть нового механизма Automatic Report Capturing в 12с. Гугление показало, что он в принципе имеет баги по CPU, и многие его отключают. 57 | 58 | 59 | ## Решение: 60 | 61 | Откючение механизма Automatic Report не помогло. Обнаружили, что имеется ошибка в настройках разделяемой памяти. /dev/shm выдано 16 байт вместо 14 ГБ планируемых. 62 | 63 | ``` 64 | more /etc/fstab 65 | ... 66 | none /dev/shm tmpfs defaults,size=16 0 0 67 | ... 68 | ``` 69 | 70 | После изменения параметра перезагрузили сервер. Проблема ушла. -------------------------------------------------------------------------------- /Oracle Errors/08104/ORA-08104_this_index_object_is_being_online_built_or_rebuilt.md: -------------------------------------------------------------------------------- 1 | # ORA-08104: this index object 3732956 is being online built or rebuilt 2 | 3 | # Версия 4 | 5 | ``` 6 | Oracle 11.2.0.4 7 | AIX 7.1 8 | ``` 9 | 10 | # Проблема 11 | 12 | При перестроении индекса с опцией online сессия зависла и была убита через alter system kill session. 13 | Далее при попытке удалить данный индекс возникает ошибка: 14 | 15 | ``` 16 | drop index SOME_INDEX; 17 | ORA-08104: this index object 3732956 is being online built or rebuilt 18 | ``` 19 | 20 | # Решение 21 | 22 | Мы можем избавиться от мусора следующей процедурой. 23 | 24 | ``` 25 | declare 26 | lv_ret BOOLEAN; 27 | begin 28 | lv_ret := dbms_repair.online_index_clean(3732956); 29 | end; 30 | / 31 | ``` -------------------------------------------------------------------------------- /Oracle Errors/16047/ORA-16047_DGID_mismatch_between_dest.md: -------------------------------------------------------------------------------- 1 | # ORA-16047 - DGID mismatch between destination setting and target database. 2 | 3 | ## Проблема 4 | 5 | В alert-логе ошибки вида 6 | 7 | ``` 8 | Wed Jun 05 18:12:55 2019 9 | PING[ARC1]: Heartbeat failed to connect to standby 'inf_stb'. Error is 16047. 10 | ``` 11 | 12 | ## Диагностика 13 | 14 | Необходимо сверить конфигурацию, прописанную в log_archive_config 15 | 16 | ``` 17 | SQL> show parameter log_archive_config 18 | 19 | NAME TYPE VALUE 20 | ------------------------------------ ----------- ------------------------------ 21 | log_archive_config string dg_config=(inf_prd,inf_stb) 22 | ``` 23 | 24 | И значения, которые прописаны в db_unique_name на обоих экземплярах (прод и стендбай). 25 | 26 | ``` 27 | SQL> show parameter db_unique_name 28 | 29 | NAME TYPE VALUE 30 | ------------------------------------ ----------- ------------------------------ 31 | db_unique_name string inf_prd 32 | ``` 33 | 34 | В данном случае на стендбае была неправильная конфигурация. Был прописан inf_prd. 35 | 36 | 37 | ## Решение 38 | 39 | Меняем на inf_stb. Перезапускаем стендбай. -------------------------------------------------------------------------------- /Oracle Errors/16525/ORA-16525_the_data_guard_broker_is_not_yet_available.md: -------------------------------------------------------------------------------- 1 | # ORA-16525: the Data Guard broker is not yet available 2 | 3 | ## Проблема 4 | 5 | При попытке сделать что-либо в dgmgrl, ошибка ORA-16525: the Data Guard broker is not yet available 6 | 7 | ## Диагностика 8 | 9 | Не запущен процесс Data Guard Broker (DMON) 10 | 11 | ``` 12 | SQL> show parameter dg_broker_start 13 | 14 | NAME TYPE VALUE 15 | ------------------------------------ ----------- ------------------------------ 16 | dg_broker_start boolean FALSE 17 | ``` 18 | 19 | ## Решение 20 | 21 | ``` 22 | SQL> alter system set dg_broker_start=true scope=both; 23 | ``` 24 | 25 | Соответствующие процессы поднимутся в экземпляре. 26 | 27 | ``` 28 | Wed Jun 05 18:40:15 2019 29 | DMON started with pid=40, OS id=24846 30 | Starting Data Guard Broker (DMON) 31 | Wed Jun 05 18:40:24 2019 32 | INSV started with pid=44, OS id=24848 33 | Wed Jun 05 18:40:55 2019 34 | NSV1 started with pid=35, OS id=24863 35 | Wed Jun 05 18:41:17 2019 36 | RSM0 started with pid=49, OS id=24877 37 | ``` -------------------------------------------------------------------------------- /Oracle Errors/19755/19750/27037/ORA-19755_ORA-19750_ORA-27037.md: -------------------------------------------------------------------------------- 1 | # ORA-19755: could not open change tracking file при DUPLICATE DATABASE 2 | 3 | ## Версии 4 | 5 | ``` 6 | SUSE Linux Enterprise Server 12 SP3 7 | 8 | Oracle Database 11.2.0.4 9 | ``` 10 | 11 | ## Проблема. 12 | 13 | Запускаем DUPLICATE DATABASE из Commvault со следующим rcv: 14 | 15 | ``` 16 | run { 17 | allocate auxiliary channel ch1 type 'sbt_tape' PARMS="SBT_LIBRARY=/opt/commvault/Base/libobk.so,ENV=(CvClientName=srv-prpsysnamep5-ora01,CvInstanceName=Instance001,CvSrcClientName=srv-sysname-ora01st)"; 18 | allocate auxiliary channel ch2 type 'sbt_tape' PARMS="SBT_LIBRARY=/opt/commvault/Base/libobk.so,ENV=(CvClientName=srv-prpsysnamep5-ora01,CvInstanceName=Instance001,CvSrcClientName=srv-sysname-ora01st)"; 19 | allocate auxiliary channel ch3 type 'sbt_tape' PARMS="SBT_LIBRARY=/opt/commvault/Base/libobk.so,ENV=(CvClientName=srv-prpsysnamep5-ora01,CvInstanceName=Instance001,CvSrcClientName=srv-sysname-ora01st)"; 20 | allocate auxiliary channel ch4 type 'sbt_tape' PARMS="SBT_LIBRARY=/opt/commvault/Base/libobk.so,ENV=(CvClientName=srv-prpsysnamep5-ora01,CvInstanceName=Instance001,CvSrcClientName=srv-sysname-ora01st)"; 21 | duplicate database sysname to sysnamePRP5 22 | UNTIL TIME "to_date('2020-09-13:21:00:00','yyyy-mm-dd:HH24:mi:ss')"; 23 | release channel ch1; 24 | release channel ch2; 25 | release channel ch3; 26 | release channel ch4; 27 | } 28 | 29 | ``` 30 | 31 | DUPLICATE сваливается со следующими ошибками 32 | 33 | ``` 34 | RMAN-00571: =========================================================== 35 | RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 36 | RMAN-00571: =========================================================== 37 | RMAN-03002: failure of Duplicate Db command at 09/18/2020 15:45:35 38 | RMAN-05501: aborting duplication of target database 39 | RMAN-03015: error occurred in stored script Memory Script 40 | ORA-00283: recovery session canceled due to errors 41 | RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u01/oracle/recovery_area/sysnamePRP5/archivelog/2020_09_18/o1_mf_1_64129_hp9bydm4_.arc' 42 | ORA-00283: recovery session canceled due to errors 43 | ORA-19755: could not open change tracking file 44 | ORA-19750: change tracking file: '/u01/oracle/block_change_tracking/rman_change_track.f' 45 | ORA-27037: unable to obtain file status 46 | Linux-x86_64 Error: 2: No such file or directory 47 | Additional information: 3 48 | 49 | ``` 50 | 51 | ## Диагностика. 52 | 53 | В процессе разработки скрипта выявлен Bug 18371441: RMAN DUPLICATE FAILS TO CREATE BCT FILE 54 | Необходимо для 11.2.0.4 установить соответствующий патч на целевой БД, на основной ставить нет необходимости. 55 | 56 | В последующих релизах предположительно исправлено. 57 | 58 | ## Решение. 59 | 60 | Установить патч p18371441_112040_Linux-x86-64.zip -------------------------------------------------------------------------------- /Oracle Errors/19838/ORA-19838.md: -------------------------------------------------------------------------------- 1 | # ORA-19838: Cannot use this control file to open database 2 | 3 | ## Проблема. 4 | 5 | DUPLICATE для тестовой БД на том же сервере, что и исходная, свалился со следующими ошибками: 6 | 7 | ``` 8 | RMAN-00571: =========================================================== 9 | RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 10 | RMAN-00571: =========================================================== 11 | RMAN-03002: failure of Duplicate Db command at 04/11/2019 20:02:59 12 | RMAN-05501: aborting duplication of target database 13 | RMAN-03015: error occurred in stored script Memory Script 14 | RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1564 and starting SCN of 10150258145227 15 | ``` 16 | 17 | ## Диагностика. 18 | 19 | При попытке открыться в новом экземпляре имеем следующие ошибки. 20 | 21 | ```sql 22 | SQL> alter database open; 23 | alter database open 24 | * 25 | ERROR at line 1: 26 | ORA-19838: Cannot use this control file to open database 27 | ``` 28 | 29 | ## Решение. 30 | 31 | Создаём текстовый трейс контрольного файла: 32 | 33 | ```sql 34 | SQL> alter database backup controlfile to trace as '/tmp/control_TEST2.sql'; 35 | SQL> shutdown immediate; 36 | ``` 37 | 38 | В контрольнике нас интересует секция **Set \#2. RESETLOGS case** 39 | Не забываем проверить, что пути правильные, и не ссылаются на существующие файлы от исходной БД. 40 | Запускаем вручную. 41 | 42 | ```sql 43 | STARTUP NOMOUNT 44 | CREATE CONTROLFILE REUSE DATABASE "PROD" RESETLOGS FORCE LOGGING ARCHIVELOG 45 | MAXLOGFILES 16 46 | MAXLOGMEMBERS 3 47 | MAXDATAFILES 100 48 | MAXINSTANCES 8 49 | MAXLOGHISTORY 41192 50 | LOGFILE 51 | GROUP 1 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_1.log' SIZE 1024M BLOCKSIZE 512, 52 | GROUP 2 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_2.log' SIZE 1024M BLOCKSIZE 512, 53 | GROUP 3 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_3.log' SIZE 1024M BLOCKSIZE 512, 54 | GROUP 4 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_4.log' SIZE 1024M BLOCKSIZE 512, 55 | GROUP 5 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_5.log' SIZE 1024M BLOCKSIZE 512 56 | -- STANDBY LOGFILE 57 | DATAFILE 58 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-system_fno-1', 59 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-sysaux_fno-2', 60 | '/u01/app/oracle/oradata/TEST2/datafile/PRIKLAD_DATA.dbf', 61 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_fno-4', 62 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_index_fno-5', 63 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_lob_fno-6', 64 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_logs_2015_fno-7', 65 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_main_fno-8', 66 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_nolog_fno-9', 67 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_nolog_idx_fno-10', 68 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-users_fno-11', 69 | '/u01/app/oracle/oradata/TEST2/datafile/undo02.313.995138821', 70 | '/u01/app/oracle/oradata/TEST2/datafile/undo02.308.995138821' 71 | CHARACTER SET CL8MSWIN1251 72 | ; 73 | ``` 74 | 75 | Контрольник создаётся. Однако, БД рассогласована из-за того, что архивные логи уехали на ленту во время нашего клонирования. 76 | 77 | ```sql 78 | SQL> select CHECKPOINT_CHANGE# from v$datafile_header; 79 | 80 | CHECKPOINT_CHANGE# 81 | ------------------ 82 | 10150258164497 83 | 10150258164498 84 | 10150258164862 85 | 10150258145284 86 | 10150258145283 87 | 10150258158654 88 | 10150258161769 89 | 10150258164669 90 | 10150258160568 91 | 10150258164909 92 | 10150258164915 93 | 10150258163328 94 | 10150258163981 95 | 96 | 13 rows selected. 97 | ``` 98 | 99 | При попытке открыться получим закономерную ошибку: 100 | 101 | ``` 102 | SQL> alter database open resetlogs; 103 | alter database open resetlogs 104 | * 105 | ERROR at line 1: 106 | ORA-01152: file 1 was not restored from a sufficiently old backup 107 | ORA-01110: data file 1: '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-system_fno-1' 108 | ``` 109 | 110 | Восстанавливаем логи с ленты. Каталогизируем их в RMAN. Запускаем процесс восстановления. 111 | 112 | ``` 113 | RMAN> catalog start with '/u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12'; 114 | 115 | 116 | RMAN> catalog start with '/u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12'; 117 | 118 | using target database control file instead of recovery catalog 119 | searching for all files that match the pattern /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12 120 | 121 | List of Files Unknown to the Database 122 | ===================================== 123 | File Name: /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1584_gc0sshvg_.arc 124 | ... 125 | 126 | Do you really want to catalog the above files (enter YES or NO)? yes 127 | cataloging files... 128 | cataloging done 129 | 130 | List of Cataloged Files 131 | ======================= 132 | File Name: /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1584_gc0sshvg_.arc 133 | ... 134 | ``` 135 | 136 | Запускаем RECOVER. 137 | 138 | ``` 139 | RMAN> recover database; 140 | 141 | Starting recover at 12-04-2019 13:25:52 142 | using target database control file instead of recovery catalog 143 | allocated channel: ORA_DISK_1 144 | channel ORA_DISK_1: SID=570 device type=DISK 145 | 146 | starting media recovery 147 | 148 | archived log for thread 1 with sequence 1564 is already on disk as file /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1564_gc0ss4wz_.arc 149 | ... 150 | archived log file name=/u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1585_gc0sshvm_.arc thread=1 sequence=1585 151 | unable to find archived log 152 | archived log thread=1 sequence=1586 153 | RMAN-00571: =========================================================== 154 | RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 155 | RMAN-00571: =========================================================== 156 | RMAN-03002: failure of recover command at 04/12/2019 13:26:24 157 | RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1586 and starting SCN of 10150258377231 158 | ``` 159 | 160 | В конце сваливается, т.к. нет текущего онлайн-лога. Но нас это не интересует для тестового экземпляра. Главное, что БД теперь в согласованном состоянии. 161 | 162 | ``` 163 | SQL> select CHECKPOINT_CHANGE# from v$datafile; 164 | 165 | CHECKPOINT_CHANGE# 166 | ------------------ 167 | 10150258377231 168 | 10150258377231 169 | 10150258377231 170 | 10150258377231 171 | 10150258377231 172 | 10150258377231 173 | 10150258377231 174 | 10150258377231 175 | 10150258377231 176 | 10150258377231 177 | 10150258377231 178 | 10150258377231 179 | 10150258377231 180 | 181 | 13 rows selected. 182 | ``` 183 | 184 | Открываем БД. 185 | 186 | ```sql 187 | SQL> alter database open resetlogs; 188 | 189 | Database altered. 190 | ``` 191 | 192 | Темп-файлы надо досоздать. Это было в трейсе контрольника. 193 | 194 | ```sql 195 | SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/temp01.dbf' REUSE; 196 | SQL> ALTER TABLESPACE PRIKLAD_TEMP ADD TEMPFILE '/u01/app/oracle/oradata/PRIKLAD_temp.dbf' REUSE; 197 | ``` 198 | 199 | Переименовываем БД утилитой NID, отключаем режим ARCHIVELOG. **PROFIT.** 200 | -------------------------------------------------------------------------------- /Oracle Errors/19838/ORA-19838.txt: -------------------------------------------------------------------------------- 1 | Проблема. 2 | 3 | DUPLICATE для тестовой БД на том же сервере, что и исходная, свалился со следующими ошибками: 4 | 5 | RMAN-00571: =========================================================== 6 | RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 7 | RMAN-00571: =========================================================== 8 | RMAN-03002: failure of Duplicate Db command at 04/11/2019 20:02:59 9 | RMAN-05501: aborting duplication of target database 10 | RMAN-03015: error occurred in stored script Memory Script 11 | RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1564 and starting SCN of 10150258145227 12 | 13 | 14 | Диагностика. 15 | 16 | При попытке открыться в новом экземпляре имеем следующие ошибки. 17 | 18 | SQL> alter database open; 19 | alter database open 20 | * 21 | ERROR at line 1: 22 | ORA-19838: Cannot use this control file to open database 23 | 24 | 25 | Решение. 26 | 27 | Создаём текстовый трейс контрольного файла: 28 | 29 | SQL> alter database backup controlfile to trace as '/tmp/control_TEST2.sql'; 30 | SQL> shutdown immediate; 31 | 32 | 33 | В контрольнике нас интересует секция Set #2. RESETLOGS case 34 | Не забываем проверить, что пути правильные, и не ссылаются на существующие файлы от исходной БД. 35 | Запускаем вручную. 36 | 37 | STARTUP NOMOUNT 38 | CREATE CONTROLFILE REUSE DATABASE "PROD" RESETLOGS FORCE LOGGING ARCHIVELOG 39 | MAXLOGFILES 16 40 | MAXLOGMEMBERS 3 41 | MAXDATAFILES 100 42 | MAXINSTANCES 8 43 | MAXLOGHISTORY 41192 44 | LOGFILE 45 | GROUP 1 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_1.log' SIZE 1024M BLOCKSIZE 512, 46 | GROUP 2 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_2.log' SIZE 1024M BLOCKSIZE 512, 47 | GROUP 3 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_3.log' SIZE 1024M BLOCKSIZE 512, 48 | GROUP 4 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_4.log' SIZE 1024M BLOCKSIZE 512, 49 | GROUP 5 '/u01/app/oracle/oradata/TEST2/onlinelog/redo_5.log' SIZE 1024M BLOCKSIZE 512 50 | -- STANDBY LOGFILE 51 | DATAFILE 52 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-system_fno-1', 53 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-sysaux_fno-2', 54 | '/u01/app/oracle/oradata/TEST2/datafile/PRIKLAD_DATA.dbf', 55 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_fno-4', 56 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_index_fno-5', 57 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_lob_fno-6', 58 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_logs_2015_fno-7', 59 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_main_fno-8', 60 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_nolog_fno-9', 61 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-PRIKLAD_nolog_idx_fno-10', 62 | '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-users_fno-11', 63 | '/u01/app/oracle/oradata/TEST2/datafile/undo02.313.995138821', 64 | '/u01/app/oracle/oradata/TEST2/datafile/undo02.308.995138821' 65 | CHARACTER SET CL8MSWIN1251 66 | ; 67 | 68 | Контрольник создаётся. Однако, БД рассогласована из-за того, что архивные логи уехали на ленту во время нашего клонирования. 69 | 70 | SQL> select CHECKPOINT_CHANGE# from v$datafile_header; 71 | 72 | CHECKPOINT_CHANGE# 73 | ------------------ 74 | 10150258164497 75 | 10150258164498 76 | 10150258164862 77 | 10150258145284 78 | 10150258145283 79 | 10150258158654 80 | 10150258161769 81 | 10150258164669 82 | 10150258160568 83 | 10150258164909 84 | 10150258164915 85 | 10150258163328 86 | 10150258163981 87 | 88 | 13 rows selected. 89 | 90 | 91 | При попытке открыться получим закономерную ошибку: 92 | 93 | SQL> alter database open resetlogs; 94 | alter database open resetlogs 95 | * 96 | ERROR at line 1: 97 | ORA-01152: file 1 was not restored from a sufficiently old backup 98 | ORA-01110: data file 1: '/u01/app/oracle/oradata/TEST2/datafile/data_d-PROD_ts-system_fno-1' 99 | 100 | 101 | Восстанавливаем логи с ленты. Каталогизируем их в RMAN. Запускаем процесс восстановления. 102 | 103 | RMAN> catalog start with '/u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12'; 104 | 105 | 106 | RMAN> catalog start with '/u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12'; 107 | 108 | using target database control file instead of recovery catalog 109 | searching for all files that match the pattern /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12 110 | 111 | List of Files Unknown to the Database 112 | ===================================== 113 | File Name: /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1584_gc0sshvg_.arc 114 | ... 115 | 116 | Do you really want to catalog the above files (enter YES or NO)? yes 117 | cataloging files... 118 | cataloging done 119 | 120 | List of Cataloged Files 121 | ======================= 122 | File Name: /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1584_gc0sshvg_.arc 123 | ... 124 | 125 | 126 | Запускаем RECOVER. 127 | 128 | RMAN> recover database; 129 | 130 | Starting recover at 12-04-2019 13:25:52 131 | using target database control file instead of recovery catalog 132 | allocated channel: ORA_DISK_1 133 | channel ORA_DISK_1: SID=570 device type=DISK 134 | 135 | starting media recovery 136 | 137 | archived log for thread 1 with sequence 1564 is already on disk as file /u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1564_gc0ss4wz_.arc 138 | ... 139 | archived log file name=/u01/app/oracle/fast_recovery_area/PROD_ORA05/archivelog/2019_04_12/o1_mf_1_1585_gc0sshvm_.arc thread=1 sequence=1585 140 | unable to find archived log 141 | archived log thread=1 sequence=1586 142 | RMAN-00571: =========================================================== 143 | RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 144 | RMAN-00571: =========================================================== 145 | RMAN-03002: failure of recover command at 04/12/2019 13:26:24 146 | RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1586 and starting SCN of 10150258377231 147 | 148 | 149 | В конце сваливается, т.к. нет текущего онлайн-лога. Но нас это не интересует для тестового экземпляра. Главное, что БД теперь в согласованном состоянии. 150 | 151 | SQL> select CHECKPOINT_CHANGE# from v$datafile; 152 | 153 | CHECKPOINT_CHANGE# 154 | ------------------ 155 | 10150258377231 156 | 10150258377231 157 | 10150258377231 158 | 10150258377231 159 | 10150258377231 160 | 10150258377231 161 | 10150258377231 162 | 10150258377231 163 | 10150258377231 164 | 10150258377231 165 | 10150258377231 166 | 10150258377231 167 | 10150258377231 168 | 169 | 13 rows selected. 170 | 171 | 172 | Открываем БД. 173 | 174 | SQL> alter database open resetlogs; 175 | 176 | Database altered. 177 | 178 | Темп-файлы надо досоздать. Это было в трейсе контрольника. 179 | 180 | ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/temp01.dbf' REUSE; 181 | ALTER TABLESPACE PRIKLAD_TEMP ADD TEMPFILE '/u01/app/oracle/oradata/PRIKLAD_temp.dbf' REUSE; 182 | 183 | 184 | Переименовываем БД утилитой NID, отключаем режим ARCHIVELOG. PROFIT. 185 | -------------------------------------------------------------------------------- /Oracle Errors/20200/06512/ORA-20200_ORA-06512_snapshot_id_1_does_not_exist_for_this_database_instance.md: -------------------------------------------------------------------------------- 1 | # ORA-20200: Begin Snapshot Id 1 does not exist for this database/instance 2 | 3 | ## Версия 4 | 5 | 11.2.0.4 6 | 7 | ## Изменения 8 | 9 | Нет 10 | 11 | ## Диагностика 12 | 13 | При попытке построить AWR-отчёт через 14 | 15 | ``` 16 | @?/rdbms/admin/awrrpt 17 | ``` 18 | 19 | Появляются ошибки: 20 | 21 | ``` 22 | ORA-20200: Begin Snapshot Id 1 does not exist for this database/instance 23 | ORA-06512: at line 22 24 | ``` 25 | 26 | Проверяем, включена ли статистика. 27 | 28 | ``` 29 | SQL> show parameter statistics_level 30 | 31 | NAME TYPE VALUE 32 | ------------------------------------ ----------- ------------------------------ 33 | statistics_level string TYPICAL 34 | ``` 35 | 36 | Проверяем расписание снятия снапшотов AWR. 37 | 38 | ``` 39 | SELECT 40 | EXTRACT(DAY FROM snap_interval) * 24 * 60 + EXTRACT(HOUR FROM snap_interval) * 60 + EXTRACT(MINUTE FROM snap_interval) snapshot_interval, 41 | EXTRACT(DAY FROM retention) * 24 * 60 + EXTRACT(HOUR FROM retention) * 60 + EXTRACT(MINUTE FROM retention) retention_interval 42 | FROM 43 | dba_hist_wr_control; 44 | 45 | SNAPSHOT_INTERVAL RETENTION_INTERVAL 46 | ----------------- ------------------ 47 | 60 11520 48 | ``` 49 | 50 | Всё в норме. Попробуем вручную снять снапшот. 51 | 52 | ``` 53 | EXEC dbms_workload_repository.create_snapshot; 54 | 55 | ERROR at line 1: 56 | ORA-13509: error encountered during updates to a AWR table 57 | ORA-01683: unable to extend index ORA-01683: unable to extend index SYS.WRH$_LATCH_PK partition WRH$_LATCH_1152737313_0 by 1024 in tablespace SYSAUX 58 | . partition by in tablespace 59 | ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 99 60 | ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 122 61 | ORA-06512: at line 1 62 | ``` 63 | 64 | 65 | ## Решение 66 | 67 | 1. Забилось табличное пространство SYSAUX. Необходимо расширить существующий файл, либо добавить дополнительный. 68 | 2. Проверить, почему забилось место. Возможно, логами аудита в таблице SYS.AUD$ -------------------------------------------------------------------------------- /Oracle Errors/27492/ORA-27492.md: -------------------------------------------------------------------------------- 1 | # ORA-27492: unable to run job scheduler unavailable 2 | 3 | ## Проблема. 4 | 5 | Вопрос из чата. As Is... 6 | 7 | ``` 8 | Народ, помогите плиз. 9 | После вчерашнего переполнения логов (почистили востановили база работает) 10 | Теперь не работает ни один джоб 11 | ORA-27492 12 | В алертлоге ошибок нету 13 | job_queue_processes=1000 14 | ``` 15 | 16 | ## Диагностика. 17 | 18 | Проверить статус шедулера. 19 | ``` 20 | select * from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED'; 21 | 22 | False 23 | ``` 24 | 25 | Попробовали перезапустить джоб-процессы. 26 | 27 | ``` 28 | alter system set job_queue_processes = 0; 29 | alter system set job_queue_processes = 1000; 30 | ``` 31 | 32 | Также не дало результатов. 33 | 34 | 35 | ## Решение. 36 | 37 | Это баг. Данное поведение описано в DBMS Scheduler Jobs Does not run Automatically and Manual run Errors out With ORA-27492 (Doc ID 1590864.1) 38 | 39 | Была предпринята неудачная попытка перезапуска экземпляра. Когда вызывается shutdown, Oracle дизейблит шедулер, но по ряду причин процесс шатдауна был отменён. Это оставило шедулер в неконсистентном состоянии, что привело к невозможности запуска джобов. 40 | 41 | Корректная перезагрузка экземпляра решает проблему. 42 | 43 | ``` 44 | SQL> SHUTDOWN IMMEDIATE; 45 | SQL> STARTUP; 46 | ``` -------------------------------------------------------------------------------- /Oracle Errors/38784/ORA-38784_ORA-01153.md: -------------------------------------------------------------------------------- 1 | # Ошибки ORA-38784, ORA-01153 2 | 3 | ## Диагностика 4 | 5 | При попытке создания точки восстановления на стендбае получаем: 6 | 7 | ```sql 8 | SQL> CREATE RESTORE POINT before_20190507_01 GUARANTEE FLASHBACK DATABASE; 9 | CREATE RESTORE POINT before_20190507_01 GUARANTEE FLASHBACK DATABASE 10 | * 11 | ERROR at line 1: 12 | ORA-38784: Cannot create restore point 'BEFORE_20190507_01'. 13 | ORA-01153: an incompatible media recovery is active 14 | ``` 15 | 16 | Удостоверяемся, что запущен процесс наката логов. 17 | 18 | ```sql 19 | SQL> select process,status from V$MANAGED_STANDBY where process='MRP0'; 20 | 21 | PROCESS STATUS 22 | --------- ------------ 23 | MRP0 APPLYING_LOG 24 | ``` 25 | 26 | ## Решение: 27 | 28 | Остановить процесс наката логов: 29 | 30 | ```sql 31 | SQL> alter database recover managed standby database cancel; 32 | 33 | Database altered. 34 | ``` 35 | 36 | Повторяем попытку: 37 | 38 | ```sql 39 | SQL> CREATE RESTORE POINT before_20190507_01 GUARANTEE FLASHBACK DATABASE; 40 | 41 | Restore point created. 42 | ``` -------------------------------------------------------------------------------- /Oracle Errors/Зависания без ошибок/RMAN/Ресинхронизация RMAN каталога зависает.md: -------------------------------------------------------------------------------- 1 | # Ресинхронизация RMAN каталога зависает на неопределённый срок. 2 | 3 | ## Проблема 4 | 5 | Ресинхронизация RMAN каталога повисает на неопределённый срок. 6 | В трейсе RMAN наблюдаются в цикле сообщения вида: 7 | 8 | ``` 9 | … 10 | DBGRPC: krmxrpc - channel default kpurpc2 err=0 db=rcvcat proc=RMAN.DBMS_RCVCAT.CHECKRMANSTATUS excl: 0 11 | DBGRCVCAT: checkRmanStatus - inserting into rsr 12 | DBGRCVCAT: checkRmanStatus - this_dbinc_key:779077 13 | DBGRCVCAT: checkRmanStatus - recid: 164495 14 | DBGRCVCAT: checkRmanStatus - stamp: 807429602 15 | DBGRCVCAT: checkRmanStatus - srecid: 164495 16 | DBGRCVCAT: checkRmanStatus - sstamp: 807429602 17 | DBGRESYNC: channel default: Calling checkRmanStatus for 164496 with status COMPLETED [15:59:05.131] (resync) 18 | … 19 | ``` 20 | 21 | ## Диагностика 22 | 23 | Никаких нот на металинке явно указывающих на данную проблему я не нашёл. Однако, есть подозрения, что зависание связано с огромным размером секции RMAN_STATUS в контрольном файле базы. В данном случае она имеет порядка 960000 записей. Для сравнения, аналогичная секция в другой базе, которая была добавлена в каталог, имеет всего 30000 записей. 24 | 25 | Посмотреть текущий размер секции можно запросом: 26 | 27 | ```sql 28 | SQL> select TYPE,RECORD_SIZE,RECORDS_TOTAL,RECORDS_USED from V$CONTROLFILE_RECORD_SECTION where TYPE='RMAN STATUS'; 29 | 30 | TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED 31 | ---------------------------- ----------- ------------- ------------ 32 | RMAN STATUS 116 960512 960512 33 | ``` 34 | 35 | ## Решение 36 | 37 | > Применять на свой риск!!! 38 | 39 | Можно очистить данную секцию следующей процедурой: 40 | 41 | ```sql 42 | exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(28); 43 | ``` 44 | 45 | > Я пробовал проводить подобные операции с секциями RMAN STATUS, ARCHIVED LOG и некоторыми другими, касающимися бэкапов BACKUP* 46 | > Однако, следует быть крайне внимательным, чтобы не очистить секцию, например, с файлами данных. 47 | 48 | 49 | > NOTE: 50 | > 51 | > If you clear a controlfile section using undocumented event, then you also need to update high_al_recid in the node table for that database to 0 in 52 | > recovery catalog. 53 | > 54 | > For 11g recovery catalog schema and above: 55 | > 56 | > update node set high_al_recid = 0 where db_unique_name = ' 58 | > For 10gR2 recovery catalog schema and below: 59 | > 60 | > update dbinc set high_al_recid = 0 where db_name = ''; 61 | 62 | 63 | 64 | 65 | -------------------------------------------------------------------------------- /Performance Tuning/Resource Manager/resource_manager.md: -------------------------------------------------------------------------------- 1 | select * from dba_users; 2 | select * from dba_profiles; 3 | 4 | begin 5 | DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA; 6 | end; 7 | / 8 | 9 | begin 10 | dbms_resource_manager.create_pending_area(); 11 | end; 12 | / 13 | 14 | select * from dict where table_name like '%RSRC%'; 15 | 16 | select * from DBA_RSRC_PLANS order by plan; 17 | select * from DBA_RSRC_CONSUMER_GROUPS order by consumer_group; 18 | 19 | BEGIN 20 | DBMS_RESOURCE_MANAGER.clear_pending_area(); 21 | DBMS_RESOURCE_MANAGER.create_pending_area(); 22 | END; 23 | / 24 | 25 | begin 26 | dbms_resource_manager.create_plan( 27 | plan => 'HPSM_DB_RSRC_PLAN', 28 | comment => 'Resource manager plan for users in HPSM database', 29 | mgmt_mth => 'EMPHASIS'); 30 | end; 31 | / 32 | 33 | BEGIN 34 | DBMS_RESOURCE_MANAGER.create_consumer_group( 35 | consumer_group => 'HPSM_CONSUMER_GROUP', 36 | comment => 'Consumer group for HPSM'); 37 | 38 | DBMS_RESOURCE_MANAGER.create_consumer_group( 39 | consumer_group => 'KPISPI_CONSUMER_GROUP', 40 | comment => 'Consumer group for KPISPI'); 41 | END; 42 | / 43 | 44 | BEGIN 45 | DBMS_RESOURCE_MANAGER.create_plan_directive ( 46 | plan => 'HPSM_DB_RSRC_PLAN', 47 | group_or_subplan => 'HPSM_CONSUMER_GROUP', 48 | comment => 'High Priority', 49 | mgmt_p1 => 100, 50 | mgmt_p2 => 0, 51 | parallel_degree_limit_p1 => 4, 52 | utilization_limit => 70); 53 | 54 | DBMS_RESOURCE_MANAGER.create_plan_directive ( 55 | plan => 'HPSM_DB_RSRC_PLAN', 56 | group_or_subplan => 'KPISPI_CONSUMER_GROUP', 57 | comment => 'Low Priority', 58 | mgmt_p1 => 0, 59 | mgmt_p2 => 100, 60 | parallel_degree_limit_p1 => 4, 61 | utilization_limit => 20); 62 | 63 | DBMS_RESOURCE_MANAGER.create_plan_directive( 64 | plan => 'HPSM_DB_RSRC_PLAN', 65 | group_or_subplan => 'OTHER_GROUPS', 66 | comment => 'all other users - level 3', 67 | mgmt_p1 => 0, 68 | mgmt_p2 => 0, 69 | mgmt_p3 => 100, 70 | utilization_limit => 10); 71 | END; 72 | / 73 | 74 | BEGIN 75 | DBMS_RESOURCE_MANAGER.validate_pending_area; 76 | DBMS_RESOURCE_MANAGER.submit_pending_area(); 77 | END; 78 | / 79 | 80 | 81 | BEGIN 82 | -- Assign users to consumer groups 83 | DBMS_RESOURCE_MANAGER_PRIVS.grant_switch_consumer_group( 84 | grantee_name => 'HPSM', 85 | consumer_group => 'HPSM_CONSUMER_GROUP', 86 | grant_option => FALSE); 87 | 88 | DBMS_RESOURCE_MANAGER_PRIVS.grant_switch_consumer_group( 89 | grantee_name => 'KPISPI', 90 | consumer_group => 'KPISPI_CONSUMER_GROUP', 91 | grant_option => FALSE); 92 | 93 | DBMS_RESOURCE_MANAGER.set_initial_consumer_group('HPSM', 'HPSM_CONSUMER_GROUP'); 94 | 95 | DBMS_RESOURCE_MANAGER.set_initial_consumer_group('KPISPI', 'KPISPI_CONSUMER_GROUP'); 96 | END; 97 | / 98 | 99 | commit; 100 | 101 | ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'HPSM_DB_RSRC_PLAN' scope=both; -------------------------------------------------------------------------------- /Performance Tuning/Resource Manager/resource_manager.txt: -------------------------------------------------------------------------------- 1 | select * from dba_users; 2 | select * from dba_profiles; 3 | 4 | begin 5 | DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA; 6 | end; 7 | / 8 | 9 | begin 10 | dbms_resource_manager.create_pending_area(); 11 | end; 12 | / 13 | 14 | select * from dict where table_name like '%RSRC%'; 15 | 16 | select * from DBA_RSRC_PLANS order by plan; 17 | select * from DBA_RSRC_CONSUMER_GROUPS order by consumer_group; 18 | 19 | BEGIN 20 | DBMS_RESOURCE_MANAGER.clear_pending_area(); 21 | DBMS_RESOURCE_MANAGER.create_pending_area(); 22 | END; 23 | / 24 | 25 | begin 26 | dbms_resource_manager.create_plan( 27 | plan => 'HPSM_DB_RSRC_PLAN', 28 | comment => 'Resource manager plan for users in HPSM database', 29 | mgmt_mth => 'EMPHASIS'); 30 | end; 31 | / 32 | 33 | BEGIN 34 | DBMS_RESOURCE_MANAGER.create_consumer_group( 35 | consumer_group => 'HPSM_CONSUMER_GROUP', 36 | comment => 'Consumer group for HPSM'); 37 | 38 | DBMS_RESOURCE_MANAGER.create_consumer_group( 39 | consumer_group => 'KPISPI_CONSUMER_GROUP', 40 | comment => 'Consumer group for KPISPI'); 41 | END; 42 | / 43 | 44 | BEGIN 45 | DBMS_RESOURCE_MANAGER.create_plan_directive ( 46 | plan => 'HPSM_DB_RSRC_PLAN', 47 | group_or_subplan => 'HPSM_CONSUMER_GROUP', 48 | comment => 'High Priority', 49 | mgmt_p1 => 80, 50 | mgmt_p2 => 0, 51 | parallel_degree_limit_p1 => 4, 52 | utilization_limit => 70); 53 | 54 | DBMS_RESOURCE_MANAGER.create_plan_directive ( 55 | plan => 'HPSM_DB_RSRC_PLAN', 56 | group_or_subplan => 'KPISPI_CONSUMER_GROUP', 57 | comment => 'Low Priority', 58 | mgmt_p1 => 0, 59 | mgmt_p2 => 80, 60 | parallel_degree_limit_p1 => 4, 61 | utilization_limit => 20); 62 | 63 | DBMS_RESOURCE_MANAGER.create_plan_directive( 64 | plan => 'HPSM_DB_RSRC_PLAN', 65 | group_or_subplan => 'OTHER_GROUPS', 66 | comment => 'all other users - level 3', 67 | mgmt_p1 => 0, 68 | mgmt_p2 => 0, 69 | mgmt_p3 => 100, 70 | utilization_limit => 10); 71 | END; 72 | / 73 | 74 | BEGIN 75 | DBMS_RESOURCE_MANAGER.validate_pending_area; 76 | DBMS_RESOURCE_MANAGER.submit_pending_area(); 77 | END; 78 | / 79 | 80 | 81 | BEGIN 82 | -- Assign users to consumer groups 83 | DBMS_RESOURCE_MANAGER_PRIVS.grant_switch_consumer_group( 84 | grantee_name => 'HPSM', 85 | consumer_group => 'HPSM_CONSUMER_GROUP', 86 | grant_option => FALSE); 87 | 88 | DBMS_RESOURCE_MANAGER_PRIVS.grant_switch_consumer_group( 89 | grantee_name => 'KPISPI', 90 | consumer_group => 'KPISPI_CONSUMER_GROUP', 91 | grant_option => FALSE); 92 | 93 | DBMS_RESOURCE_MANAGER.set_initial_consumer_group('HPSM', 'HPSM_CONSUMER_GROUP'); 94 | 95 | DBMS_RESOURCE_MANAGER.set_initial_consumer_group('KPISPI', 'KPISPI_CONSUMER_GROUP'); 96 | END; 97 | / 98 | 99 | commit; 100 | 101 | ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'HPSM_DB_RSRC_PLAN' scope=both; -------------------------------------------------------------------------------- /Performance Tuning/SQL Management/SQL Plan Baselines/copy_plan_from_one_sql_id_to_another.md: -------------------------------------------------------------------------------- 1 | # Копирование плана запроса из одного sql_id в другой sql_id 2 | 3 | Такой подход может быть полезен, если у одного запроса план плохой, но у такого же, но отличающегося в незначительных деталях, хороший. 4 | Таким образом можно создать также новый план на основе Bind-переменных. 5 | 6 | 1. Находим необходимый sql_id 7 | 8 | ```sql 9 | select sql_id, sql_text, plan_hash_value 10 | from v$sql 11 | where sql_text like '%I_DIR1%' 12 | order by last_active_time; 13 | ``` 14 | 15 | Его также можно найти в AWR отчёте, OEM и в прочих местах 16 | 17 | 2. Загрузка плана настроенного запроса 18 | 19 | ```sql 20 | declare 21 | l_sql_id_src varchar2(13) :='4wu5ab1df1cak'; -- sql_id с хорошим планом. Тот, что хотим закрепить 22 | l_plan_hash_value_src number := 1357081020; -- plan_hash_value тот самый хороший план 23 | l_sql_id_trg varchar2(13) :='ck30v97vj5n5z'; -- sql_id с плохим планом, куда мы хотим прикрепить хороший 24 | l_sql_text_trg clob; 25 | l_res number; 26 | begin 27 | -- текст запроса для настройки 28 | select a.sql_fulltext into l_sql_text_trg 29 | from v$sqlarea a 30 | where a.sql_id = l_sql_id_trg; 31 | -- загрузка плана и создание SQL plan baseline 32 | l_res := dbms_spm.load_plans_from_cursor_cache( 33 | sql_id => l_sql_id_src, 34 | plan_hash_value => l_plan_hash_value_src, 35 | sql_text => l_sql_text_trg); 36 | dbms_output.put_line(l_res); 37 | end; 38 | / 39 | ``` 40 | 41 | План загружается в SQL Plan Baseline. 42 | Посмотреть созданный бейзлайн можно так: 43 | 44 | ```sql 45 | select * from dba_sql_plan_baselines order by created desc; 46 | ``` 47 | 48 | -------------------------------------------------------------------------------- /Performance Tuning/SQL Management/SQL Plan Baselines/load_sql_plan_from_awr_into_sql_baseline.md: -------------------------------------------------------------------------------- 1 | # Загрузка планов запросов из AWR в SQL Plan Baseline 2 | 3 | 1. Определение, для каких запросов имеется статистика выполнения 4 | 5 | ```sql 6 | SELECT DISTINCT PLAN_HASH_VALUE,SQL_ID FROM DBA_HIST_SQLSTAT WHERE SQL_ID='43h973m25jv68'; 7 | ``` 8 | 9 | 2. Вывод различных статистик для планов выполнения. 10 | 11 | ```sql 12 | SELECT SS.SNAP_ID, 13 | SS.INSTANCE_NUMBER, 14 | BEGIN_INTERVAL_TIME, 15 | SQL_ID, 16 | PLAN_HASH_VALUE,OPTIMIZER_COST, 17 | DISK_READS_TOTAL, 18 | BUFFER_GETS_TOTAL, 19 | ROWS_PROCESSED_TOTAL, 20 | CPU_TIME_TOTAL, 21 | ELAPSED_TIME_TOTAL, 22 | IOWAIT_TOTAL, 23 | NVL (EXECUTIONS_DELTA, 0) EXECS, 24 | ( ELAPSED_TIME_DELTA 25 | / DECODE (NVL (EXECUTIONS_DELTA, 0), 0, 1, EXECUTIONS_DELTA)) 26 | / 1000000 27 | AVG_ETIME, 28 | ( BUFFER_GETS_DELTA 29 | / DECODE (NVL (BUFFER_GETS_DELTA, 0), 0, 1, EXECUTIONS_DELTA)) 30 | AVG_LIO 31 | FROM DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS 32 | WHERE SQL_ID = '43h973m25jv68' 33 | AND SS.SNAP_ID = S.SNAP_ID 34 | AND SS.INSTANCE_NUMBER = S.INSTANCE_NUMBER 35 | AND EXECUTIONS_DELTA > 0 36 | ORDER BY 1, 2, 3; 37 | ``` 38 | 39 | Пример группировки по CPU_TIME_TOTAL. 40 | 41 | ```sql 42 | select round(plan_hash_value),avg(cpu_time_total) from ( 43 | SELECT SS.SNAP_ID, 44 | SS.INSTANCE_NUMBER, 45 | BEGIN_INTERVAL_TIME, 46 | SQL_ID, 47 | PLAN_HASH_VALUE,OPTIMIZER_COST, 48 | DISK_READS_TOTAL, 49 | BUFFER_GETS_TOTAL, 50 | ROWS_PROCESSED_TOTAL, 51 | CPU_TIME_TOTAL, 52 | ELAPSED_TIME_TOTAL, 53 | IOWAIT_TOTAL, 54 | NVL (EXECUTIONS_DELTA, 0) EXECS, 55 | ( ELAPSED_TIME_DELTA 56 | / DECODE (NVL (EXECUTIONS_DELTA, 0), 0, 1, EXECUTIONS_DELTA)) 57 | / 1000000 58 | AVG_ETIME, 59 | ( BUFFER_GETS_DELTA 60 | / DECODE (NVL (BUFFER_GETS_DELTA, 0), 0, 1, EXECUTIONS_DELTA)) 61 | AVG_LIO 62 | FROM DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS 63 | WHERE SQL_ID = '43h973m25jv68' 64 | AND SS.SNAP_ID = S.SNAP_ID 65 | AND SS.INSTANCE_NUMBER = S.INSTANCE_NUMBER 66 | AND EXECUTIONS_DELTA > 0 67 | ORDER BY 1, 2, 3 68 | ) group by round(plan_hash_value) 69 | order by 2; 70 | ``` 71 | 72 | 3. Создание SQL Tuning Set для хранения планов данного запроса. 73 | 74 | ```sql 75 | BEGIN 76 | DBMS_SQLTUNE.CREATE_SQLSET( 77 | sqlset_name => 'STS_43h973m25jv68', 78 | description => 'SQL Tuning Set for 43h973m25jv68'); 79 | END; 80 | / 81 | ``` 82 | 83 | 4. Загрузка планов запросов из AWR в SQL Tuning Set 84 | 85 | begin_snap и end_snap можно взять из запроса: 86 | 87 | ```sql 88 | select min(snap_id) "begin_snap", max(snap_id) "end_snap" from dba_hist_snapshot; 89 | ``` 90 | 91 | ```sql 92 | DECLARE 93 | cur sys_refcursor; 94 | BEGIN 95 | OPEN cur FOR 96 | SELECT VALUE(p) 97 | FROM TABLE(DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY(begin_snap=>7913, end_snap=>8113,basic_filter=>'sql_id = ''43h973m25jv68''',attribute_list=>'ALL') 98 | ) p; 99 | DBMS_SQLTUNE.LOAD_SQLSET( sqlset_name=> 'STS_43h973m25jv68', populate_cursor=>cur); 100 | CLOSE cur; 101 | END; 102 | / 103 | ``` 104 | 105 | Также, как вариант, загрузить можно не из AWR, и из CURSOR_CACHE, если нас интересуют лишь те запросы, которые находятся там. 106 | 107 | ```sql 108 | DECLARE 109 | cur sys_refcursor; 110 | BEGIN 111 | OPEN cur FOR 112 | SELECT VALUE(p) 113 | FROM TABLE(DBMS_SQLTUNE.SELECT_CURSOR_CACHE(basic_filter=>'sql_id = ''43h973m25jv68''',attribute_list=>'ALL') 114 | ) p; 115 | DBMS_SQLTUNE.LOAD_SQLSET( sqlset_name=> 'STS_43h973m25jv68', populate_cursor=>cur); 116 | CLOSE cur; 117 | END; 118 | / 119 | ``` 120 | 121 | 5. Посмотреть загруженную информацию 122 | 123 | ```sql 124 | SELECT 125 | first_load_time , 126 | executions as execs , 127 | parsing_schema_name , 128 | elapsed_time / 1000000 as elapsed_time_secs , 129 | cpu_time / 1000000 as cpu_time_secs , 130 | buffer_gets , 131 | disk_reads , 132 | direct_writes , 133 | rows_processed , 134 | fetches , 135 | optimizer_cost , 136 | sql_plan , 137 | plan_hash_value , 138 | sql_id , 139 | sql_text 140 | FROM TABLE(DBMS_SQLTUNE.SELECT_SQLSET(sqlset_name => 'STS_43h973m25jv68') 141 | ); 142 | ``` 143 | 144 | На данном этапе в SQL Tuning Set'е может находиться довольно много запросов. И, если загрузить все из них в качестве SQL Plan Baseline, то все автоматически получат статус Accepted. Я так и не нашёл способ, как на это повлиять. 145 | Поэтому, грузим лишь тот план запроса, который выполняется в данный момент. Примем его за базовый (условно хороший, если хоть как-то выполняется). Для этого вычистим из STS все планы, кроме него. 146 | 147 | ```sql 148 | BEGIN 149 | DBMS_SQLTUNE.DELETE_SQLSET ( 150 | sqlset_name => 'STS_43h973m25jv68' 151 | , basic_filter => 'plan_hash_value != 150806729' 152 | ); 153 | END; 154 | / 155 | ``` 156 | 157 | Можно проверить содержимое STS запросом выше. 158 | 159 | 6. Загрузка планов из SQL Tuning Set в SQL Plan Baseline. 160 | 161 | ```sql 162 | DECLARE 163 | my_plans pls_integer; 164 | BEGIN 165 | my_plans := DBMS_SPM.LOAD_PLANS_FROM_SQLSET( 166 | sqlset_name => 'STS_43h973m25jv68' 167 | ); 168 | END; 169 | / 170 | ``` 171 | 172 | 7. Evolve Baseline 173 | 174 | Если всё ок, один базовый план загружен, работает, и Oracle AUTO-CAPTURE нашёл и добавил ещё некоторые планы. Они будут не Accepted. Для их использования их необходимо верифицировать. 175 | Проводим процедуру верификации так 176 | 177 | ```sql 178 | SET LONG 100000 179 | SELECT DBMS_SPM.evolve_sql_plan_baseline(sql_handle => 'SQL_a9fb2c232750c314') FROM dual; 180 | ``` 181 | 182 | Либо так 183 | 184 | ```sql 185 | DECLARE 186 | res varchar(32767); 187 | BEGIN 188 | res := DBMS_SPM.evolve_sql_plan_baseline(sql_handle => 'SQL_a9fb2c232750c314'); 189 | DBMS_OUTPUT.put_line('Evolved: ' || res); 190 | END; 191 | / 192 | ``` 193 | 194 | Если один из имеющихся планов имеет лучшую производительность, чем базовый план, он будет принят (Accepted), и начнёт использоваться в запросах. 195 | 196 | 197 | **P.S.** Если что-то пошло не так 198 | 199 | Посмотреть загруженную информацию по запросу можно: 200 | 201 | ```sql 202 | select * from dba_sql_plan_baselines order by created desc; 203 | ``` 204 | 205 | Если уже знаем название плана, и надо узнать лишь SQL_HANDLE, то так: 206 | 207 | ```sql 208 | select * from dba_sql_plan_baselines where plan_name = 'SQL_PLAN_amytc4cmp1hsn268d3985'; 209 | select * from dba_sql_plan_baselines where sql_handle = 'SQL_a9fb2c232750c314' order by accepted desc; 210 | ``` 211 | 212 | Удалить отдельный план из бейзлайна, либо весь бейзлайн: 213 | 214 | ```sql 215 | SET SERVEROUTPUT ON 216 | DECLARE 217 | l_plans_dropped PLS_INTEGER; 218 | BEGIN 219 | l_plans_dropped := DBMS_SPM.drop_sql_plan_baseline ( 220 | sql_handle => 'SQL_a9fb2c232750c314', 221 | plan_name => 'SQL_PLAN_amytc4cmp1hsn268d3985'); 222 | 223 | DBMS_OUTPUT.put_line(l_plans_dropped); 224 | END; 225 | / 226 | ``` 227 | 228 | **P.P.S.** В случае, если требуется зафиксировать какой-то конкретный план: 229 | 230 | ```sql 231 | SET SERVEROUTPUT ON 232 | DECLARE 233 | l_plans_altered PLS_INTEGER; 234 | BEGIN 235 | l_plans_altered := DBMS_SPM.alter_sql_plan_baseline( 236 | sql_handle => 'SQL_d4ab20f5c5a232b7', 237 | plan_name => 'SQL_PLAN_d9at0yr2u4cpr217cac12', 238 | attribute_name => 'fixed', 239 | attribute_value => 'YES'); 240 | 241 | DBMS_OUTPUT.put_line('Plans Altered: ' || l_plans_altered); 242 | END; 243 | / 244 | ``` -------------------------------------------------------------------------------- /Performance Tuning/SQL Monitoring/blocking_sessions.md: -------------------------------------------------------------------------------- 1 | # Блокировки в БД 2 | 3 | ```sql 4 | SELECT SUBSTR(TO_CHAR(w.session_id),1,5) WSID, p1.spid WPID, 5 | SUBSTR(s1.username,1,12) "WAITING User", 6 | SUBSTR(s1.osuser,1,8) "OS User", 7 | SUBSTR(s1.program,1,20) "WAITING Program", 8 | s1.client_info "WAITING Client", 9 | SUBSTR(TO_CHAR(h.session_id),1,5) HSID, p2.spid HPID, 10 | SUBSTR(s2.username,1,12) "HOLDING User", 11 | SUBSTR(s2.osuser,1,8) "OS User", 12 | SUBSTR(s2.program,1,20) "HOLDING Program", 13 | s2.client_info "HOLDING Client", 14 | o.owner || '.' || o.object_name "HOLDING Object" 15 | FROM gv$process p1, gv$process p2, gv$session s1, 16 | gv$session s2, dba_locks w, dba_locks h, dba_objects o 17 | WHERE w.last_convert > 60 18 | AND h.mode_held != 'None' 19 | AND h.mode_held != 'Null' 20 | AND w.mode_requested != 'None' 21 | AND s1.row_wait_obj# = o.object_id 22 | AND w.lock_type(+) = h.lock_type 23 | AND w.lock_id1(+) = h.lock_id1 24 | AND w.lock_id2 (+) = h.lock_id2 25 | AND w.session_id = s1.sid (+) 26 | AND h.session_id = s2.sid (+) 27 | AND s1.paddr = p1.addr (+) 28 | AND s2.paddr = p2.addr (+) 29 | ORDER BY w.last_convert DESC; 30 | ``` -------------------------------------------------------------------------------- /Performance Tuning/SQL Monitoring/sql_plan_by_hour.md: -------------------------------------------------------------------------------- 1 | # Планы выполнения запросов по часам 2 | 3 | В действительности по AWR-снапшотам. Могут быть чаще, чем раз в час. 4 | 5 | ```sql 6 | SELECT instance_number AS inst 7 | , ( snap_id - 1 ) AS begin_snap_id 8 | ,TO_CHAR (sn.begin_interval_time,'dd.mm hh24:mi') AS begin_snap_time 9 | ,TO_CHAR (sn.end_interval_time,'dd.mm hh24:mi') AS end_snap_time 10 | ,round (st.executions_delta) AS execs 11 | ,trunc (st.executions_delta / 3600,1) AS execs_per_sec 12 | ,st.sql_id 13 | ,st.plan_hash_value AS plan 14 | ,st.optimizer_cost AS cost 15 | ,round (st.parse_calls_delta / DECODE (st.executions_delta,0,1,st.executions_delta),3) AS parse_per_exec 16 | ,round (st.elapsed_time_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS ela_per_exec_micro 17 | ,round (st.cpu_time_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS cpu_per_exec 18 | ,round (st.buffer_gets_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS gets_per_exec 19 | ,round (st.physical_read_bytes_delta / DECODE (st.executions_delta,0,1,st.executions_delta) / 1024 / 1024) AS read_mb_per_exec 20 | ,round (st.physical_read_requests_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS reads_per_exec 21 | ,round (st.physical_write_bytes_delta / DECODE (st.executions_delta,0,1,st.executions_delta) / 1024 / 1024) AS writes_mb_per_exec 22 | ,round (st.physical_write_requests_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS writes_per_exec 23 | ,round (st.direct_writes_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS direct_writes_per_exec 24 | ,round (st.rows_processed_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS rows_per_exec 25 | ,round (st.fetches_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS fetches_per_exec 26 | ,round (st.iowait_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS iowaits_per_exec 27 | ,round (st.clwait_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS clwaits_per_exec 28 | ,round (st.apwait_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS apwaits_per_exec 29 | ,round (st.ccwait_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS ccwaits_per_exec 30 | ,round (st.parse_calls_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS parse_per_exec 31 | ,round (st.plsexec_time_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS plsql_per_exec 32 | ,round (st.px_servers_execs_delta / DECODE (st.executions_delta,0,1,st.executions_delta) ) AS px_per_exec 33 | FROM dba_hist_sqlstat st 34 | JOIN dba_hist_snapshot sn 35 | USING ( snap_id 36 | ,instance_number ) 37 | WHERE sql_id = '0kt89qhr8k31b' AND sn.begin_interval_time > SYSDATE - 7 38 | ORDER BY snap_id DESC 39 | ,instance_number; 40 | ``` -------------------------------------------------------------------------------- /SQL/Hints/DRIVING_SITE.md: -------------------------------------------------------------------------------- 1 | # Hint DRIVING_SITE 2 | 3 | Столкнулся с проблемой, когда в запросе происходит объединение локальной маленькой таблицы, и огромной удалённой. 4 | Без хинта локальный хост пытался вытянуть данные с удалённого. 5 | 6 | select /*+ DRIVING_SITE */ rs.column1 7 | from remote_table1@remote_site rs 8 | join local_table1 lt 9 | on rs.id = lt.id; -------------------------------------------------------------------------------- /SQL/XML/xml_extract_value_from_clob_column.md: -------------------------------------------------------------------------------- 1 | # Oracle XML. Extract value from CLOB column. 2 | 3 | Имеем некоторый XML документ в поле CLOB в таблице. Пример: 4 | 5 | ```xml 6 | 7 | 8 | 9 | ce3ea3c3-3fdf-4641-98c5-d90ff534256b 10 | 12345 11 | 12 | ContAtt 13 | 14 | 15 | 6840159228036 16 | 1234567890 17 | 1234567890@somedomain.com 18 | 19 | 20 | 17341657178036 21 | Специальность 22 | 23 | 24 | ``` 25 | 26 | Необходимо достать из него pat/id 27 | 28 | ``` 29 | with mytest as ( 30 | select XMLType(message) as xml from lukyanov.ESU_OUTPUT 31 | ) 32 | select t.xml.extract('//pat/id/text()').getStringVal() from 33 | mytest t; 34 | ``` 35 | 36 | Если нужно встроить обращение к полю в условие запроса, то так: 37 | 38 | ``` 39 | select * from lukyanov.ESU_OUTPUT where XMLType(message).extract('//pat/id/text()').getStringVal() in (6840159228036); 40 | ``` 41 | 42 | Для ускорения выполнения запроса можно создать функциональный индекс на поле. 43 | 44 | ``` 45 | drop index lukyanov.FUN_ESU_OUTPUT; 46 | create index lukyanov.FUN_ESU_OUTPUT on lukyanov.ESU_OUTPUT(to_number(XMLType(message).extract('//pat/id/text()').getStringVal())); 47 | ``` -------------------------------------------------------------------------------- /Stored Procedures/C/c_stored_procedure.md: -------------------------------------------------------------------------------- 1 | # Хранимая процедура на C в Oracle 2 | 3 | 1. Создаём простую процедуру на Си, которая выполняет любую передаваемую команду в операционной системе 4 | 5 | ``` 6 | #include 7 | #include 8 | #include 9 | 10 | void sh(char*); 11 | 12 | void sh(char* cmd) { 13 | system(cmd); 14 | } 15 | ``` 16 | 17 | 2. Компиляция библиотеки 18 | 19 | После создания файла с исходным кодом из него необходимо скомпилировать саму либу, для чего воспользуемся gcc и ld. Допустим исходник имеет название shell.c. 20 | 21 | ``` 22 | gcc -fPIC -DSHARED_OBJECT -c shell.c 23 | ld -shared -o shell.so shell.o 24 | ``` 25 | 26 | 3. Создание внешней библиотеки как объекта в Oracle 27 | 28 | ``` 29 | create or replace library shell_lib is '$ORACLE_HOME/bin/shell.so'; 30 | ``` 31 | 32 | 4. Создание процедуры в БД, которая будет вызывать данную библиотеку 33 | 34 | ``` 35 | create or replace procedure shell(cmd IN char) 36 | as external name "sh" library shell_lib language C parameters (cmd string); 37 | ``` 38 | 39 | На вход процедуры передаётся строка с командой, которую необходимо выполнить в ОС. -------------------------------------------------------------------------------- /Stored Procedures/Java/getSumDigits.sql: -------------------------------------------------------------------------------- 1 | -- Пример хранимой функции на Java, возвращающей сумму всех цифр, встречающихся в передаваемой строке 2 | 3 | CREATE OR REPLACE AND COMPILE JAVA SOURCE NAMED "getSumDigits" AS 4 | public class SumDigits 5 | { 6 | public static int getSumDigits(String arg) 7 | { 8 | char[] argArr = arg.toCharArray(); 9 | int sum = 0; 10 | for(int i = 0; i < arg.length(); i++){ 11 | try{ 12 | if(Character.isDigit(argArr[i])) { 13 | sum += Character.getNumericValue(argArr[i]); 14 | } 15 | }catch(Exception e){} 16 | } 17 | 18 | return sum; 19 | } 20 | } 21 | / 22 | 23 | 24 | -- Создаём обёртку для функции с описанием входных и выходных значений. 25 | -- На вход приходит VARCHAR2, на вход Java-функции передаст java.lang.String 26 | -- На выходе имеем java.lang.Integer от Java, и возвращаем Number 27 | 28 | CREATE OR REPLACE FUNCTION getSumDigits (text IN varchar2) RETURN Number 29 | IS LANGUAGE JAVA 30 | NAME 'SumDigits.getSumDigits(java.lang.String) return java.lang.Integer'; 31 | / 32 | 33 | 34 | -- Пример использования 35 | 36 | select GETSUMDIGITS('1a23bc45') as "Sum of digits" from dual; 37 | 38 | -- Возвращает: 15 39 | -------------------------------------------------------------------------------- /Stored Procedures/Java/getUniqueCount.sql: -------------------------------------------------------------------------------- 1 | -- Пример хранимой функции на Java, возвращающей число уникальных символов в строке 2 | 3 | CREATE OR REPLACE AND COMPILE JAVA SOURCE NAMED "getUniqueCount" AS 4 | public class StringCounters 5 | { 6 | 7 | public static int getUniqueCount( String arg ) 8 | { 9 | java.util.ArrayList unique = new java.util.ArrayList(); 10 | for( int i = 0; i < arg.length(); i++) 11 | if( !unique.contains( arg.charAt( i ) ) ) 12 | unique.add( arg.charAt( i ) ); 13 | 14 | return unique.size(); 15 | } 16 | } 17 | / 18 | 19 | 20 | -- Создаём обёртку для функции с описанием входных и выходных значений. 21 | -- На вход приходит VARCHAR2, на вход Java-функции передаст java.lang.String 22 | -- На выходе имеем java.lang.Integer от Java, и возвращаем Number 23 | 24 | CREATE OR REPLACE FUNCTION getUniqueCount (text IN varchar2) RETURN Number 25 | IS LANGUAGE JAVA 26 | NAME 'StringCounters.getUniqueCount(java.lang.String) return java.lang.Integer'; 27 | / 28 | 29 | 30 | -- Пример использования 31 | 32 | select GETUNIQUECOUNT('aaabbbccc') from dual; 33 | 34 | -- Возвращает: 3 -------------------------------------------------------------------------------- /Проведение регламентных работ/Точки восстановления/Удаление точек восстановления/README.md: -------------------------------------------------------------------------------- 1 | # Удаление точек восстановления 2 | 3 | ## На праймари 4 | 5 | Проверка, что точка восстановления существует: 6 | 7 | ```sql 8 | col name format a40 9 | col SCN format 999999999999999 10 | col TIME format a40 11 | col DATABASE_INCARNATION# format 999 12 | col GUARANTEE_FLASHBACK_DATABASE format a3 13 | col STORAGE_SIZE format 9999999999999 14 | SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 15 | 16 | NAME SCN TIME DATABASE_INCARNATION# GUA STORAGE_SIZE 17 | ---------------------------------------- ---------------- ---------------------------------------- --------------------- --- -------------- 18 | before_update 120242924 07-MAY-19 10.51.36.000000000 AM 2 YES 209715200 19 | ``` 20 | 21 | Удаление точки: 22 | 23 | ```sql 24 | drop restore point before_update; 25 | 26 | Restore point dropped. 27 | ``` 28 | 29 | ## На стендбае 30 | 31 | > До 12-ой версии удаление точек восстановления на стендбае требует его перезапуска. В 12-ой этот шаг можно пропустить, и сделать аналогично праймари. 32 | 33 | Проверка, что точка восстановления существует: 34 | 35 | ```sql 36 | col name format a40 37 | col SCN format 999999999999999 38 | col TIME format a40 39 | col DATABASE_INCARNATION# format 999 40 | col GUARANTEE_FLASHBACK_DATABASE format a3 41 | col STORAGE_SIZE format 9999999999999 42 | SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 43 | 44 | NAME SCN TIME DATABASE_INCARNATION# GUA STORAGE_SIZE 45 | ---------------------------------------- ---------------- ---------------------------------------- --------------------- --- -------------- 46 | before_update 120242924 07-MAY-19 10.51.36.000000000 AM 2 YES 209715200 47 | ``` 48 | 49 | Перезагружаем экземпляр. 50 | 51 | ```sql 52 | SQL> shutdown immediate; 53 | Database closed. 54 | Database dismounted. 55 | ORACLE instance shut down. 56 | ``` 57 | 58 | Запускаем в режиме MOUNT 59 | 60 | ```sql 61 | SQL> set pagesize 999 62 | SQL> set linesize 140 63 | SQL> set numf 99999999999999999 64 | SQL> startup nomount; 65 | ORACLE instance started. 66 | 67 | Total System Global Area 10956709888 bytes 68 | Fixed Size 2262976 bytes 69 | Variable Size 7482640448 bytes 70 | Database Buffers 3456106496 bytes 71 | Redo Buffers 15699968 bytes 72 | SQL> alter database mount standby database; 73 | 74 | Database altered. 75 | ``` 76 | 77 | Удаляем точку восстановления: 78 | 79 | ```sql 80 | SQL> drop restore point before_update; 81 | 82 | Restore point dropped. 83 | ``` 84 | 85 | Если стендбай работает в режиме Active Standby with log apply, то запускаем в режиме Read Only. 86 | 87 | ```sql 88 | SQL> alter database open read only; 89 | 90 | Database altered. 91 | ``` 92 | 93 | Запускаем накат логов. 94 | 95 | ```sql 96 | SQL> alter database recover managed standby database using current logfile disconnect from session; 97 | ``` 98 | 99 | > Если настроен DataGuard Broker, то он, возможно, уже успел запустить процесс наката логов сам. Тогда ничего дополнительно делать не нужно. 100 | 101 | ```sql 102 | SQL> alter database recover managed standby database using current logfile disconnect from session; 103 | alter database recover managed standby database using current logfile disconnect from session 104 | * 105 | ERROR at line 1: 106 | ORA-01153: an incompatible media recovery is active 107 | ``` -------------------------------------------------------------------------------- /Проведение регламентных работ/Точки восстановления/Установка точек восстановления/README.md: -------------------------------------------------------------------------------- 1 | # Установка точек восстановления 2 | 3 | > Точки восстановления устанавливаются сперва на стендбае, затем на основной базе. 4 | 5 | ## На стендбае 6 | 7 | Проверяем роль БД, включён ли режим Flashback. 8 | 9 | ```sql 10 | SQL> select name,database_role,open_mode,flashback_on,log_mode from v$database; 11 | 12 | NAME DATABASE_ROLE OPEN_MODE FLASHBACK_ON LOG_MODE 13 | --------- ---------------- -------------------- ------------------ ------------ 14 | PCAREEVE PRIMARY READ WRITE YES ARCHIVELOG 15 | ``` 16 | 17 | Проверяем, существуют ли уже другие точки восстановления. 18 | 19 | ```sql 20 | SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 21 | 22 | no rows selected 23 | ``` 24 | 25 | Проверка, запущен ли процесс Recover. 26 | 27 | ```sql 28 | SQL> select process,status from V$MANAGED_STANDBY where process='MRP0'; 29 | 30 | PROCESS STATUS 31 | --------- ------------ 32 | MRP0 APPLYING_LOG 33 | 34 | ``` 35 | 36 | Если попытаться создать точку при включённом процессе наката, ругается: 37 | 38 | ```sql 39 | SQL> CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE; 40 | CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE 41 | * 42 | ERROR at line 1: 43 | ORA-38784: Cannot create restore point 'BEFORE_update'. 44 | ORA-01153: an incompatible media recovery is active 45 | ``` 46 | 47 | Останавливаем процесс наката: 48 | 49 | ```sql 50 | SQL> alter database recover managed standby database cancel; 51 | 52 | Database altered. 53 | ``` 54 | 55 | Устанавливаем точку восстановления: 56 | 57 | ```sql 58 | SQL> CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE; 59 | 60 | Restore point created. 61 | ``` 62 | 63 | Проверяем, что точка установлена: 64 | 65 | ```sql 66 | SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 67 | 68 | NAME 69 | -------------------------------------------------------------------------------------------------------------------------------- 70 | SCN TIME DATABASE_INCARNATION# GUA STORAGE_SIZE 71 | ------------------ --------------------------------------------------------------------------- --------------------- --- ------------------ 72 | before_update 73 | 120242243 07-MAY-19 10.51.13.000000000 AM 2 YES 104857600 74 | 75 | ``` 76 | 77 | Можно запустить накат логов, чтобы стендбай был актуален во время проведения работ. 78 | 79 | ```sql 80 | SQL> alter database recover managed standby database using current logfile disconnect from session; 81 | 82 | Database altered. 83 | ``` 84 | 85 | 86 | ## На праймари 87 | 88 | Проверяем роль БД, включён ли режим Flashback. 89 | 90 | ```sql 91 | SQL> select name,database_role,open_mode,flashback_on,log_mode from v$database; 92 | 93 | NAME DATABASE_ROLE OPEN_MODE FLASHBACK_ON LOG_MODE 94 | --------- ---------------- -------------------- ------------------ ------------ 95 | PCAREEVE PRIMARY READ WRITE YES ARCHIVELOG 96 | ``` 97 | 98 | Проверяем, существуют ли уже другие точки восстановления. 99 | 100 | ```sql 101 | SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 102 | 103 | no rows selected 104 | ``` 105 | 106 | Устанавливаем точку восстановления: 107 | 108 | ```sql 109 | SQL> CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE; 110 | 111 | Restore point created. 112 | ``` 113 | 114 | Проверяем, что точка установлена: 115 | 116 | ```sql 117 | SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 118 | 119 | NAME 120 | -------------------------------------------------------------------------------------------------------------------------------- 121 | SCN TIME DATABASE_INCARNATION# GUA STORAGE_SIZE 122 | ----------------- --------------------------------------------------------------------------- --------------------- --- ----------------- 123 | before_update 124 | 120242924 07-MAY-19 10.51.36.000000000 AM 2 YES 104857600 125 | ``` 126 | 127 | --------------------------------------------------------------------------------