Oracle
 sql >> база данни >  >> RDS >> Oracle

Архиваторът прекъсна поради СЪВМЕСТИМИЯ ORA-16484

Тази сутрин се събудих с няколко сигнала от EM за закачането на моя архиватор, подобно на следното:

Target type=Database Instance 
Target name=orcl4 
Categories=Fault 
Message=The archiver hung at time/line number: Fri Sep 09 06:07:22 2016/376. 
Severity=Critical

Използвах DG Broker, за да спра и след това да рестартирам транспортирането на журнали.

edit database orcl set state=transport-off;
edit database orcl set state=transport-on;

Но архиваторът все пак щеше да се закачи. Така че отиваме в дневника за предупреждения, за да получите повече улики. Намерих това в основния регистър на предупрежденията:

TT00: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16484)
TT00: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Fri Sep 09 08:07:40 2016
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl4/trace/orcl4_tt00_16068.trc:
ORA-16484: compatibility setting is too low

Съобщението за грешка изглежда разбираемо. Имам COMPATIBLE настроен твърде ниско. В този момент си спомних, че смених COMPATIBLE в първичните преди месец. Сигурно съм забравил да променя и това в режим на готовност. Бърза проверка доказа хипотезата ми. COMPATIBLE е настроен на 12.1.0.2 в основния, но 11.2.0 в режим на готовност. Значи там е моят проблем. Смених COMPATIBLE в режим на готовност, върнах го и след това възобнових транспортирането на дневници. Животът беше наред и всичко беше оправено.

Ако си спомняте правилно, казах, че смених COMPATIBLE в първичните преди месец. Защо това беше проблем днес, а не тогава? За да знаете това, трябва да знаете историята на промените за тази база данни. Снощи пуснахме нов код за производство. Част от изданието на кода беше да включва нова таблица, която използва новата функция на колоната IDENTITY на Oracle 12c. Това беше първата функция само за 12c, която внедрихме в нашата кодова база. Режимът на готовност се опитваше да създаде таблицата с новата функция, но тази операция не можа да завърши поради неправилна настройка на параметрите. Все още съм малко объркан как това повлия на транспортирането на дървени трупи. Бих очаквал, че само приложението за регистрационни файлове ще бъде повредено, но това се прояви така.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Защо моето песимистично заключване в JPA с Oracle не работи

  2. .patch_storage

  3. Oracle:разлика между max(id)+1 и sequence.nextval

  4. Изходът на скрипта на SQL Developer съкращава ширината на sys_refcursor

  5. Как да разрешите ORA-011033:В ход е инициализация или изключване на ORACLE