Ошибки Оракла ORA-00000

Ошибки Оракла ORA-00000 – ORA-00999

Группы первой тысячи ошибок Oracle (по диапазонам кодов от 0 до 999):

Сообщения об ошибках ORA-00000 – ORA-00099

Сообщения ORA-00000 – нормальное, успешное завершение, т.е., не ошибка.

Методологические ошибки доступа к ядру 0001-0049

Ошибки управления входом в БД Оракл и выходом из неё:

Сообщения об ошибках ORA-00500 – ORA-00599

1. Измените параметры 2. ОТКРОЙТЕ базу данных, удалите текущую область отмены и заново создайте новую область отмены. 3. Измените параметры. 4. Перезапустите базу данных.

Successfully onlined Undo Tablespace 54.

Mon Nov 21 11:34:03 2016

SMON: enabling tx recovery

Database Characterset is UTF8

Mon Nov 21 11:34:04 2016

Non-fatal internal error happenned SMON was doing temporary segment drop.

SMON encountered 1 out of maximum 100 non-fatal internal errors.

Mon Nov 21 11:35:04 2016

Flush retried xcb 0x4419143b0, pmd 0x4401e3c90

SMON encountered 6 out of maximum 100 non-fatal internal errors.

Mon Nov 21 11:35:05 2016

PMON: terminating instance due to error 472

Instance terminated by PMON, pid = 7510

Ошибки Оракла ORA-00000

Эта ошибка, официальный документStep by step to resolve ORA-600 4194 4193 4197 on database crash (Идентификатор документа 1428786.1)Предоставляется подробное введение. Перед обработкой рекомендуется ознакомиться с вторичным документом,Основная сцена ошибки:

This issue generally occurs when there is a power outage or hardware failure that initially crashes the database. On startup, the database does the normal roll forward (redo) and then rollback (undo), this is where the error is generated on the rollback.

Конкретная операция выглядит следующим образом

Шаг 1. Сгенерируйте pfile через создание spfile

Шаг 2. Завершите работу экземпляра базы данных

Шаг 3. Измените undo_management в pfile на ВРУЧНУЮ

Шаг 4. Используйте PFILE для запуска базы данных

*Plus: Release 10.2.0.4.0 – Production Mon Nov 21 11:51:59 2016

Connected an idle instance.

ORACLE instance started.

Total System Area 1.0737E+10 bytes

Fixed 2101808 bytes

Buffers 4244635648 bytes

Redo Buffers 14671872 bytes

Step 5:This is critical – we are looking for all undo segments to be offline – System will always be online.

If any are ‘PARTLY AVAILABLE’ or ‘NEEDS RECOVERY’ – Please open an issue with Oracle Support or update the current SR. There are many options from this moment and Oracle Support Analyst can offer different solutions for the bad undo segments.

If all offline then continue to the next step

TABLESPACE_NAME                STATUS           SEGMENT_NAME

—————————— —————- ——————————

SYSTEM                         ONLINE           SYSTEM

Шаг 6. Создайте новое табличное пространство UNDO.

3  4G;

Шаг 7. Удалите старое табличное пространство UNDO.

Шаг 8: закройте экземпляр базы данных

ORACLE instance shut down.

Disconnected Oracle 10g Release 10.2.0.4.0 – 64bit Production

Шаг 9. Переведите экземпляр базы данных в состояние NOMOUNT.

Total System Area 1.6777E+10 bytes

Fixed                   2113368 bytes

Buffers         6777995264 bytes

Redo Buffers               14663680 bytes

Шаг 10: Измените параметр undo_tablespace в spfile

Setp 11: Закройте экземпляр базы данных.

Шаг 12: Запустите экземпляр базы данных (используя spfile)

Пошаговое решение проблемы ORA-600 4194 4193 4197 при сбое базы данных (идентификатор документа 1428786.1)

In this Document

This error indicates that a mismatch has been detected between redo records and rollback (undo) records.

Best practice to create a new undo tablespace. This method includes segment check.

1. Shutdown the instance

If any are ‘PARTLY AVAILABLE’ or ‘NEEDS RECOVERY’ – Please open an issue with Oracle Support or update the current SR.  There are many options from this moment and Oracle Support Analyst can offer different solutions for the bad undo segments.

6. Drop old undo tablespace including contents and datafiles;

9 modify the spfile with the new undo tablespace name

Alter system set undo_tablespace = ‘

● Эта статья находится в itpub (http://blog.itpub.net/26736162/abstract/1/), блог-сад (http://www.cnblogs.com/lhrbest) И личный публичный аккаунт WeChat (xiaomaimiaolhr) Синхронизировано

● Адрес itpub этой статьи:http://blog.itpub.net/26736162/abstract/1/

● Адрес блогового сада этой статьи:http://www.cnblogs.com/lhrbest

● Версия этой статьи в формате pdf, личный профиль и адрес облачного диска про рассаду пшеницы:http://blog.itpub.net/26736162/viewspace-1624453/

● Номер группы QQ:230161599(полный)、618766405

● Группа WeChat: добавьте меня в WeChat, я соберу всех в группу, если вы один

● Свяжитесь со мной, пожалуйста, добавьте друзей из QQ., Укажите причину добавления

● Завершено в Magic City с 1 сентября 2017 года с 9:00 до 30 сентября 2017 года с 22:00.

● Содержание статьи взято из примечаний к исследованию сеянцев пшеницы, а некоторые из них собраны из Интернета. Пожалуйста, поймите, есть ли какие-либо нарушения или нарушения.

● Магазин саженцев пшеницы WeChat:https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

● Серия баз данных, опубликованная Wheat Seedling:http://blog.itpub.net/26736162/viewspace-2142121/

использоватьОтсканируйте QR-код ниже, чтобы следить за публичным аккаунтом WeChat о саженцах пшеницы (xiaomaimiaolhr) И группа QQ (коллекция DBA),Изучите наиболее практичную технологию баз данных.

Ошибки Оракла ORA-00000

Ошибки Оракла ORA-00000

Ошибки Оракла ORA-00000

Ошибки Оракла ORA-00000

Публичный аккаунт WeChat о саженцах пшеницы Группа QQ сбора саженцев пшеницы DBA 1Рассады пшеницыQQ группа 2Магазин WeChat от Wheat Seed

взят из «блога ITPUB», ссылка: http://blog.itpub.net/26736162/viewspace-2144770/, если вам нужно перепечатать, укажите источник, в противном случае будет преследоваться юридическая ответственность.

Внезапное появление застало людей врасплох (натянутая улыбка).

Официальные документы для таких ошибок:

решение: Просто смени его на 2g

Автор признателен руководителям и сотрудникам ЗАО «Нефтегазсистемы»,
начальникам и персоналу вычислительных центров региональных управлений ОАО «Транснефть»,
c чьей помощью был разработан и внедрен данный Oracle-проект.

Возможные ошибки и методы их устранения

ORA-00020: maximum number of
processes (num) exceeded

/ превышено максимальное
количество процессов (ном)

Операция потребовала ресурс,
оказавшийся недоступным. Максимальное количество процессов определяется
параметром инициализации .
Когда этот максимум превышается, никакие запросы больше обрабатываться не
могут.

Повторите операцию еще раз через
несколько минут. Если это сообщение выдается часто, закройте в файле
параметров инициализации, и запустите

Требуется увеличить параметр , причем для деф-сайта этот параметр должен
быть больше, чем для дест-сайта. Для БД СИСТЕМЫ было рекомендовано
установить этот параметр в 300 для дест-сайта и 400 для деф-сайта.

ORA-00060: deadlock detected
while waiting for resource

/ во время ожидания ресурса
произошла взаимоблокировка

Активный сеанс и какой-то другой сеанс, оба ожидающие
один и тот же ресурс, заблокировали друг друга. Это состояние известно как
взаимоблокировка. Для того, чтобы выйти из взаимоблокировки, надо сделать откат
(восстановить предыдущее состояние) одной или нескольких команд, таким образом
другой сеанс сможет продолжить работу.

и перезапустите все команды, входящие в последнюю

подождите, пока блокировка не
закончится (возможно, через несколько минут), и перезапустите те команды, на
которых произошел откат.

Читайте также:  КОТЛОМОЕЧНАЯ МАШИНА DIHR LP 3 S PLUS ОШИБКИ

Ошибка может возникнуть при
перегенерации сайта на БД, куда был неудачно выполнен полный импорт БД другого
сайта (см. Часть 2, Глава 3: Перенос основной БД на сервер с другой ОС).

Попробуйте удалить мастер-группы вместе с объектами и
повторить генерацию сайта.

Это общее внутреннее сообщение для
исключительных ситуаций программ . Оно указывает, что процесс столкнулся с неожиданным
событием нижнего уровня. Причинами,
вызывающими это сообщение, могут быть:

сбойные ситуации при проверке
данных в памяти;

сообщения ввода/вывода,
аппаратного обеспечения, памяти;

Первый
аргумент – это номер внутреннего сообщения; другие аргументы – различные 
числа, имена и символьные строки. (Для получения более полной информации см. 
раздел “Обращение в службу поддержки пользователей “.)
Числа могут  меняться в зависимости от версии сервера

Отправьте описание этой ошибки в
службу поддержки пользователей , сопроводив его информацией о:

событиях, которые привели к
ошибке;

предпринятых вами действиях,
которые привели к ошибке;

состоянии операционной системы и
на момент ошибки;

подробностях всех необычных
обстоятельств, предшествовавших получению сообщения

содержимом всех файлов трассировок,
созданных в результате ошибки;

относящихся к этому случаю
реакциях сигнального файла.

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

Это одна из самых скверных ошибок.
При ее возникновении рекомендуется обратиться к группе технической поддержки .
Но существует также еще одна рекомендация: настройте работу в

ORA-01400: cannot
insert NULL into (PLIPEKN.EDITIONS.ID)

/ Пропущен первичный ключ
или обязательный

) столбец, или во время операции

ORA-06512: at
“PLIPEKN.WORKS_LOG”, line 16

ORA-04088: error
during execution of trigger ‘PLIPEKN.WORKS_LOG’

ORA-06512: at
“PLIPEKN.WORKS$RP”, line 831

ORA-01085:
preceding errors in deferred rpc to “PLIPEKN.WORKS$RP. REP_UPDATE”

ORA-02063:
preceding 5 lines from PLI_NORD

При вводе или редактировании записи Вы не задали
значение обязательного (

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

Возникает при попытке сделать изменение
в таблице при отключенном или отсутствующем триггере (который расчитывает и устанавливает системный
идентификатор записи

create or replace
trigger EDITIONS_COR

before insert
or update on EDITIONS

for each row

select
EDITIONS_SEQ.nextval into :new.ID from DUAL;

ORA-01403: data not found

/ данные не найдены

ORA-06512: на
“PLIPEKN.DRFEAT$RP”, строки 321

-01085: ошибка обработки в
задержанном

В программе на базовом языке были выбраны все записи.
Код возврата от операции равен +4. Это означает, что из запроса на были
извлечены все записи.

Прекратите обработку для данного оператора

является большим сюрпризом. Она возникает в самом важном месте – при выполнении
удаленной транзакции, и, притом, из-за множества причин, большинство которых
Вам еще не известно. Эта трудно распознаваемая ошибка обязательно будет время
от времени у Вас возникать.

Дело может быть в следующем: не
обновлено поле, по которому разрешаются конфликты (отключен или отсутствует
триггер , который расчитывает и устанавливает поле , по которому как раз и разрешаются конфликты методом – см. пример триггера выше при описании ошибки ). Эта ошибка не возникает, если транзакция по данной
записи идет одна, без встречной.

ORA-01591: lock held by
in-doubt distributed transaction 6.58.10015

/ блокировка, удерживаемая
распред. транзакцией 6.58.10015,

находящейся в неопр. сост.

Была попытка доступа к ресурсу,
заблокированному “повисшей” распределенной транзакцией, находящейся в
состоянии подготовки.

Для того, чтобы определить связь баз
данных и состояние транзакции,  сравните номер транзакции в сообщении со
столбцом .
Попытайтесь исправить сетевое соединение для координатора и узла точки
завершения транзакции, если это необходимо. Если исправление временно невозможно,
обратитесь к  администратору базы данных узла точки завершения транзакции (если
она известна), чтобы “протолкнуть” ожидающую какого-то действия
транзакцию.

Ошибка диагностирует возникновение
«смертельных объятий», зацикливании процессов друг на друге. Может возникнуть
при попытке удалить из мастер-группы дест-сайт, если одна из БД других
сайтов остановлена.

Запустите БД всех сайтов и в
состоянии мастер-группы NORMAL повторите операцию.

ORA-02049: time-out:
distributed transaction waiting for lock

/ таймаут: распределенная
транзакция ждет блокировку

Превышено время ожидания блокировки
распределенной транзакции. Это время задается в параметре инициализации

Эта ситуация трактуется как
тупиковая, поэтому происходит откат вашей команды. Установите в параметре
инициализации более длительный интервал времени ожидания; затем
закройте и перезапустите экземпляр СУБД.

Ошибка может порождаться при
возникновении «смертельных объятий», связанных с тем, что кончилось время
ожидания выполнения распределенной транзакции, заданное в конфигурационном
файле параметром

Увеличьте значение указанного
параметра и перезагрузите БД.

На момент внедрения этот параметр можно снизить до 60
(1 мин), чтобы долго не ожидать результатов выполнения небольших тестов по
проверке репликации. Во время же эксплуатации лучше увеличить этот параметр,
например, до 300 (5 мин).

Такое сообщение может появиться при выполнении
административных запросов, причем не адекватным образом, например, при переводе
группы в , затем сразу в
(для проверки). Транзакций в этом случае быть не должно (кроме, возможно,
системных). Подождите немного и повторите попытку.

Сообщение об этой ошибке однажды появилось при
одновременном добавлении сайта к двум мастер-группам (первой и последней),
причем таблицы обеих групп друг на друга не ссылались.

ORA-02266: unique/primary
keys in table referenced by enabled

/ таблица имеет некие уникальные/первичные
ключи,

на которые ссылаются внешние ключи

Была попытка уничтожить таблицу, хотя она имела еще
какие-то уникальные или первичные ключи, на которые имеются активные () ссылки внешних ключей.

Перед удалением таблицы отключите все
ссылки внешних ключей на уникальные или первичные ключи. Посмотреть имеющиеся
ссылки и их статус Вы можете с помощью следующего

select
CONSTRAINT_NAME, TABLE_NAME, STATUS

where
R_CONSTRAINT_NAME in (

инструктирует, что эта ошибка возникает при попытке сделать на
таблицу со связями. Но при репликации эта ошибка может возникнуть в случае,
если на дест-сайте таблица имеет статус

Для исправления ситуации требуется
приостановить мастер-группу (),
удалить таблицу () из
мастер-группы деф-сайта (не удаляя физически), дождаться удаления из дест-сайта,
затем опять ее добавить () и
активизировать мастер-группу (

ORA-02449: unique/primary keys in table referenced by
foreign keys

уникальный/первичный
ключ в таблице,

на которую
ссылаются по внешнему ключу

Была попытка уничтожить таблицу, хотя она имела еще
какие-то уникальные или первичные ключи, на которые ссылаются внешние ключи.

Перед удалением таблицы удалите все
ссылки внешних ключей на уникальные или первичные ключи. Посмотреть имеющиеся
ссылки Вы можете с помощью следующего

Возникает при попытке удалить таблицу
с первичным или уникальным ключем, если на нее ссылается другая таблица (см.
выше:

ORA-03113:
end-of-file on communication channel

/ конец файла по
коммуникационному каналу

Читайте также:  Сертификат безопасности для веб-сайта ru небезопасен код ошибки 0 и (Решено)

По коммуникационному каналу передан сигнал
конца файла, который не был обработан соответствующим образом программным
обеспечением (двухзадачным программным обеспечением). Это
сообщение может быть выдано, если теневой двухзадачный процесс, связанный с , завершился ненормально, или же на устройстве связи
между процессами  произошел физический сбой (сеть или сервер отключились от
коммуникации).

Если это сообщение было выдано при попытке
осуществить связь, проверьте установочные файлы для соответствующего драйвера и убедитесь, что программное обеспечение на сервере установлено правильно. Если сообщение было
выдано после того, как связь правильно установилась, и ошибка не связана с
физическим сбоем, проверьте файл трассировки, если таковой был создан на
сервере в момент сбоя. Существование файла трассировки может указать вам на то,
что эта ошибка – внутренняя ошибка , требующая вмешательства
службы поддержки пользователей

При
возникновении этой ошибки рекомендуется посмотреть трассировочные файлы (обычно
находятся в каталоге ). Как
правило, это связано с потерей связи или неисправностью на сервере, возникших
во время выполнения процесса в

Эта
ошибка часто возникает при прохождении на сервер большого пакета транзакций или
подтверждений от них (см. Часть 2, Глава 3: Если пропала связь с сервером),
но может возникнуть и во время выполнения административных запросов (например,
одновременный запуск добавления достаточно больших таблиц в несколько
мастер-групп).

ORA-04030: out of
process memory when trying to allocate 524316 bytes

/ выход за пределы
памяти процесса при попытке выделить

524316 байт (стр)

Собственная память системного
процесса исчерпана.

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

Выделяемая
под процессы память на сервере исчерпалась. Причины могут быть разные. На -сервере
это обычно происходит при фрагментации кэш-памяти и помогает только
перезагрузка сервера.

ORA-04052: error
occurred when looking up remote object

/ ошибка возникла
во время поиска удаленного объекта

ORA-00604: error
occurred at recursive SQL level 2

ORA-12154:
TNS:could not resolve service name

ORA-06512: at
“SYS.DBMS_REPCAT_MAS”, line 674

ORA-06512: at
“SYS.DBMS_REPCAT”, line 516

Ошибка возникла во время поиска
удаленного объекта.

Исправьте ошибку. Убедитесь, что на
удаленной базе данных были запущены все необходимые командные файлы создания
представлений данных, используемых для запроса/поиска объектов базы данных. См.
книгу Сервер 7. Руководство администратора.

Посмотрите, не «уронили» ли Вы при этом сервер. Если
да – перезапустите его.

ORA-06502: PL/SQL:
numeric or value error

: ошибка в числе или в
значении

Произошла ошибка арифметическая, числовая, строковая,
преобразования или правила целостности. Например, такая ошибка  может произойти
при попытке присвоить значение
переменной, описанной как , или при
попытке присвоить целое, больше переменной, описанной как

Измените данные, которыми вы манипулируете, или  их
описание таким образом, чтобы они не противоречили друг другу.

Ошибка может возникнуть при
перегенерации сайта на БД, куда уже был выполнен полный импорт БД другого сайта
(см. Часть 2, Глава 3: Перенос основной БД на сервер с другой ОС).

Необходимо удалить мастер-группы вместе с объектами и
повторить генерацию сайта (на самом деле так просто отделаться от этой ошибки
не всегда удается).

ORA-12011: execution of 1
jobs failed

/ сбой при выполнении 1
задания

ORA-06512: at “SYS.DBMS_IJOB”, line 255

ORA-06512: at “SYS.DBMS_JOB”,
line 218

ORA-06512: at line 2

обнаружил ошибку. Запуск одного или нескольких
заданий привел к ошибке, которую не удалось обработать.

Посмотрите в журнале предупреждений,
какое задание не смогло запуститься и почему.

Ошибка возникает при попытке
запустить задачу , которая до этого
находилась в состоянии , причем, предварительный перевод ее в состояние не помогает –
задача или сама через некоторое время устанавливается в , или это происходит после попытки ее запустить. Это может произойти по
причине выполненного ранее  выполнилось автоматически при установке в это
состояние пакета транзакций).

ORA-23308: object
PLIPEKN.COUNTRY$RU does not exist or is invalid

/ объект PLIPEKN.COUNTRY$RU
либо неправильный,

Указанное имя введено неправильно или
пусто, заданный тип неправилен, объект не является правильным объектом базы данных
или не существует как тиражируемый объект с соответствующим состоянием.

Проверьте, что объект существует,
доступен пользователю и, если требуется, является правильным объектом в списке

Ошибка возникает при несоответствии
структуры таблицы одного сайта с другим (например, при перегенерации
репликационной поддержки).

Тщательно сверьте структуру указанной
таблицы на деф-сайте и дест-сайте. Возможно, на деф-сайте
была изменена ее структура, типы полей или ограничения вне DDL-механизма ORM.

Эта ошибка может создать заколдованный круг: при ее удалении на дест-сайте вне
DDL-механизма ORM остаются неудаленными модули и операции для этой таблицы на деф-сайте вызывает ошибку.
Удаление вышеназванных модулей тоже не помогает. Не помогает также
соответствующая операция для этой таблицы в БД дест-сайта
(вне ORM). При попытке удаления этой таблицы из мастер-группы деф-сайта
(с тем, чтобы это удаление распространилось на дест-сайт) также
возникает ошибочный административный запрос, поскольку из мастер-группы дест-сайта
в этом случае нельзя удалить таблицу с несоответствующей структурой.

Рекомендуется следующее: сделайте соответствующую
операцию для этой таблицы в БД дест-сайта
через механизм ORM. Если при этом также возникнет ошибка можно поступить
иначе: удалите таблицу из БД дест-сайта с помощью SQL*Plus
(отключив предварительно ограничения) и создайте заново (можно пустую). Затем
можно попытаться удалить эту таблицу из мастер-группы деф-сайта,
подождать окончания административного запроса на обоих сайтах и вновь добавив
таблицу в мастер-группу. Если и это не поможет, то пересоздайте всю
мастер-группу путем удаления и последующего подключения к ней этого сайта с
отключенной опцией

ORA-23309: object
PLIPEKN.COUNTRY of type TABLE exists

бъект PLIPEKN.COUNTRY типа
TABLE существует

Объект уже существует в том же пространстве имен,
возможно с другим типом или формой.

Удалите объект или повторите запрос со значением

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

Удалите эту таблицу в БД дест-сайта
и повторите добавление этого сайта на мастер-группу дест-сайта.

Имя схемы пусто или неправильно введено,
запрашиваемая заданная база данных не является оригиналом, или один из
оригиналов не считает вызываемую базу данных оригиналом.

Если заданное имя схемы и оригинала
правильны, соединитесь с оригиналом и повторите запрос, или переместите

Ошибка может возникнуть при
перегенерации репликационной поддержки для сайта, где объекты имеют статус (см. Часть 2, Глава 3: Работа с административными запросами, Решение
проблем при создании мастер-групп).

Читайте также:  Коды ошибок на климате тойота авенсис

Удалите всю группу с объектами с этого сайта (или
только -объекты) и перегенерите репликацию.

ORA-23313: object
group PLIPEKN7 is not mastered at PLI_BONN.WORLD

7 не явл.главной для

Имя схемы пусто или неправильно
введено, запрашиваемая база данных не является оригиналом или запрашиваемая
база данных не считает заданную базу данных оригиналом.

Если заданное имя схемы правильно,
соединитесь с текущим оригиналом и повторите запрос, установите запрашиваемую
базу данных оригиналом с помощью , если запрашиваемая база данных является узлом копии.

Ошибка возникает, если мастер-БД с
мастер-группы деф-сайта уже удалена.

ORA-23374: object
group PLIPEKN0 already exists

ORA-06512: at
“SYS.DBMS_SYS_ERROR”, line 86

ORA-06512: at
“SYS.DBMS_REPCAT_MAS”, line 1598

ORA-06512: at
“SYS.DBMS_REPCAT”, line 113

Данная мастер-БД уже реплицирована данной
мастер-группой.

Выберите другую мастер-группу или мастер-БД.

Ошибка возникает при попытке
«прицепить» дест-сайт к мастер-группе деф-сайта, если на этом дест-сайте
такая мастер-группа уже существует. Эта ситуация возникает, если сайт пытаются
пересоздать (см. Часть 2, Глава 3: Пересоздание дест-сайта), для чего
сначала его «отрывают» от мастер-группы деф-сайта, а потом (переведя ее
в состояние ) пытаются опять присоединить.

-команды по анализу и управлению репликацией

окажутся для администратора
полезными и часто необходимыми для.
анализа и управления распределенными транзакциями. Полный синтаксис
использования -процедур и структура представлений Словаря данных
приводятся в Приложении 3  и Приложении 4, соответственно.

Анализ объектов в мастер-группе

Поиск мастер-группы для таблицы

select GNAME from
ALL_REPOBJECT

where
ONAME=’BRANCH’ and TYPE=’TABLE’;

Листинг скрипта
на подсчет записей всех таблиц БД

set feed off

set term off

set head off

set pages 10000

col L newline

prompt set head off

prompt set feed off

prompt set term on

prompt set recsep off

prompt variable iC number;;

prompt execute :iC:=0;;

R.GNAME=’PLIPEKN0′ and R.TYPE=’TABLE’ and

R.ONAME = T.TABLE_NAME

prompt select :iC from DUAL;;

–prompt set feed on

set pages 0

set pages 23

Сформированный и
запускаемый далее скрипт имеет следующий вид:

select :iC + count(*) into :iC from BRANCH;

select :iC + count(*) into :iC from CONOPF;

select
:iC + count(*) into :iC from TYPEM;

select
:iC + count(*) into :iC from TYPEOBJECT;

select
:iC from DUAL;

Кол-во модулей по всем
мастер-группам (если объекты – только
таблицы, то равно учетверенному кол-ву таблиц –

select count(*) from
ALL_REPGENERATED order by ONAME, TYPE;

Кол-во модулей по каждой
мастер-группе (очень полезный запрос):

select GNAME,
count(*) from ALL_REPOBJECT

group by GNAME

order by GNAME;

Объекты, нуждающиеся в перегенерации
репликационной поддержки

select ONAME from
ALL_REPOBJECT

-объекты на сайте (обязателен к применению):

select GNAME,
ONAME from ALL_REPOBJECT

where
STATUS=’ERROR’ and TYPE=’TABLE’ order by GNAME;

-объектов по мастер-группам:

Кол-во изменений по мастер-группам
за период времени (для определения
наиболее активных мастер-групп):

select R.GNAME,
count(A.ID) CNT

from
ALL_REPOBJECT R, EDITIONS A

R.TYPE=’TABLE’
and R.ONAME=A.TABNAME and

group by R.GNAME

Результат выполнения запроса (пример):

Анализ административных запросов

ID, to_char(TIMESTAMP,’DD.MM.YYYY HH24:MI:SS’) TIME,

substr(MASTER,1,15) MR, substr(GNAME,1,8) GR,

substr(ONAME,1,12) OB, substr(MESSAGE,1,40)

STATUS=’ERROR’ and TYPE=’TABLE’;

Административные запросы по
мастер-группе

substr(MASTER,1,15) MAST, substr(ONAME,1,12) OB,

STATUS, REQUEST, ERRNUM

Административные запросы по
мастер-сайту первой очереди (для
выявления блокирующих административных запросов):

substr(MASTER,1,15) M, substr(GNAME,1,12) G,

substr(ONAME,1,12) O, STATUS, REQUEST, ERRNUM

ROWNUM < 10;

Кол-во адм-запросов по всему
мастер-сайту (для общего контроля
выполнения):

Кол-во административных
запросов по каждой мастер-группе (для
общего контроля выполнения):

select  
substr(GNAME,1,12) GR, count(*) REQ_NUM

Кол-во каждого вида и статуса
административных запросов по каждой мастер-группе (для детального контроля выполнения):

substr(GNAME,1,12) GR, REQUEST, STATUS, count(*) REQ_NUM

GNAME, REQUEST, STATUS

Анализ транзакций

select count(*) from
DEFTRAN;

Кол-во транзакций для каждого
сайта

select
substr(DBLINK,1,20), count(*) CNT from DEFTRANDEST

group by DBLINK
order by DBLINK;

Кол-во транзакций для каждого
сайта по дням формирования

DEFTRANDEST DD,
DEFTRAN D

DL                  
ST               CT

PLI_ANTA.WORLD      
29-FEB-00       939

PLI_ANTA.WORLD      
01-MAR-00      6160

PLI_ANTA.WORLD      
02-MAR-00      7546

PLI_ANTA.WORLD      
03-MAR-00       245

PLI_ANTA.WORLD      
25-FEB-00      1580

PLI_ANTA.WORLD      
26-FEB-00       570

PLI_ANTA.WORLD      
27-FEB-00       165

. Для удаления одной транзакции (например, с
идентификатором 6.19.11941) используется следующее указывает
о применении команды ко всем мастер-сайтам):

Для удаления всех транзакций используется пустое
значение параметра

: данная функция отсутствует, но можно использовать
запуск соответствующей задачи, т.е. процесс для нужного дест-сайта,
например:

select count(*)
from DEFERROR;

Анализ журнала правок БД

В БД
рекомендуется создать и использовать специальную таблицу (например, ), куда триггерами заносятся все изменения по таблицам
Вашей системы (находящимся только в БД ). Анализ
этой таблицы полезен для сверки с выполненными и выполняемыми транзакциями.
Ниже приведен ряд полезных запросов (находятся в файле

— Сводка по таблицам и датам последних правок

select TABNAME, count(TABNAME)
C, max(CORDATE) D

group by TABNAME

order by TABNAME;

— Сводка по видам правок за диапазон дат

select ACTION, count(ACTION)
C

where trunc(CORDATE)
between trunc(SYSDATE)-2 and trunc(SYSDATE)

group by ACTION

order by ACTION;

Пример
результата данного запроса ( – добавление,
изменение, удаление):

— where to_char(CORDATE,’dd.mm.yy’)=to_char(SYSDATE-1,
‘dd.mm.yy’)

— Сводка по таблицам, которые правились за
предыдущие дни

— Все изменения (добавления) за день (для сверки с
репликацией)

select TABNAME,TABKEY,ACTION,to_char(CORDATE,’dd.mm.yy
hh:mi:ss’) DL

—   and ACTION=1

order by CORDATE;

— Общее кол-во изменений за день

select count(*) CNT

— Выборка добавленных в таблицу записей за 1 день

select T.ID, T.NAME, A.CORDATE

from PIPECROSS T, EDITIONS
A

and T.ID=A.TABKEY and A.TABNAME=’PIPECROSS’
and A.ACTION=1

order by A.

Необходимые конфигурационные параметры для репликаци

В этом пункте перечислены параметры конфигурационного
файла , являющиеся важными для работы приложений. Эти
параметры должны иметь следующие значения.

(для
репликации Мультимастер увеличить до 12-20);

(для репликации Мультимастер
увеличить до 10 – 12, т.е., примерно, удвоенное кол-во мастер-сайтов);

не менее 300

(при использовании репликации Мультимастер
увеличить: 300 на -сайте, 400 на

После внезапно закрыта виртуальная машина, запустите базу данных, отчет об ошибке:

Запрос сигнализации журналов ALTER и Trace файлы, получите причина ошибки: Поскольку сервер внезапно выключается, необходимо не удалять, когда перезапущен файл LGWR, написанный онлайн-файл журнала. Когда база данных перезапускается в следующий раз, требуется восстановление уровня экземпляра, а также эти повторенные данные Не может быть получен из онлайн-файла журнала. Когда выключение, журнал записи не удался.

Просмотр текущей ситуации журнала:

GROUP# SEQUENCE# STATUS FIRST_TIME NEXT_CHANGE#

1 42 INACTIVE 2019-03-09 03:00:53 1506891
4 43 INACTIVE 2019-03-10 10:10:21 1509950
3 41 INACTIVE 2019-03-08 00:00:17 1413500
2 44 CURRENT 2019-03-10 11:00:24 2.8147E+14

В настоящее время вторая группа журнала

GROUP# STATUS TYPE MEMBER IS_

1 ONLINE /data/tgdb/redo01.log NO
2 ONLINE /data/tgdb/redo02.log NO
3 ONLINE /data/tgdb/redo03.log NO
4 ONLINE /data/tgdb/redo04.log NO

TGDB READ WRITE

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *