Oracle ORA-01775 오류 원인과 해결 방법 완벽 가이드

ORA-01775
2026년 07월 31일 | DBMS Error 가이드

이 글에서 다루는 내용

ORA-01775 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

ORA-01775 looping chain of synonyms 는?

ORA-01775 에러는 Oracle 데이터베이스에서 동의어(Synonym)가 서로를 순환 참조하는 체인을 형성할 때 발생합니다. 즉, 동의어 A가 동의어 B를 가리키고, 동의어 B가 다시 동의어 A를 가리키는 형태처럼 끝없이 순환하는 구조가 만들어졌을 때 Oracle이 이를 감지하고 해당 에러를 발생시킵니다. 이 에러는 동의어를 통해 테이블, 뷰, 시퀀스 등의 객체에 접근하려 할 때 나타나며, 특히 여러 스키마 간의 복잡한 동의어 체인이 구성된 대규모 시스템에서 자주 목격됩니다.

주요 발생 원인

동의어 간의 직접 순환 참조 (Direct Circular Reference)

가장 흔한 원인으로, 두 개 이상의 동의어가 서로를 가리키는 순환 구조를 형성하는 경우입니다. 예를 들어 SYN_A → SYN_B → SYN_A 형태처럼 동의어 생성 시점에는 문제가 없어 보이지만, 실제 객체에 접근할 때 Oracle이 무한 루프에 빠지게 됩니다. 특히 DBA가 동의어를 교체하거나 재구성하는 과정에서 실수로 이러한 순환 구조를 만드는 경우가 많습니다.

원본 객체(Base Object)가 삭제된 후 동의어만 남은 경우

동의어가 가리키는 원본 테이블이나 뷰가 삭제되었음에도 불구하고 동의어 자체는 그대로 남아 있는 상황에서, 다른 동의어가 이 깨진 동의어를 참조하게 되면 루프로 감지되는 경우가 있습니다. Oracle은 해당 동의어 체인을 따라가다 유효한 객체를 찾지 못하면 내부적으로 순환 참조로 처리할 수 있습니다. 이런 경우는 운영 중 테이블 정리나 스키마 마이그레이션 작업 후에 자주 발생합니다.

Public Synonym과 Private Synonym 간의 충돌 및 혼용

Public Synonym과 Private Synonym이 동일한 이름으로 존재하거나, 서로를 참조하는 구조가 만들어질 때 이 에러가 발생할 수 있습니다. 특히 애플리케이션 배포 자동화 스크립트에서 동의어 DROP 없이 CREATE OR REPLACE를 반복 실행하거나, 스키마 간 동의어를 무분별하게 생성할 때 이런 문제가 발생합니다. 여러 팀이 동시에 동의어를 관리하는 환경에서는 특히 주의가 필요합니다.

해결 방법

1단계: 문제가 되는 동의어 체인 파악

먼저 현재 시스템에 존재하는 동의어 구조를 파악해야 합니다.

-- 현재 스키마의 모든 동의어 확인
SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME, DB_LINK
FROM USER_SYNONYMS
ORDER BY SYNONYM_NAME;

-- DBA 권한으로 전체 동의어 확인
SELECT OWNER, SYNONYM_NAME, TABLE_OWNER, TABLE_NAME, DB_LINK
FROM DBA_SYNONYMS
WHERE TABLE_NAME IN (
    SELECT SYNONYM_NAME FROM DBA_SYNONYMS
)
ORDER BY OWNER, SYNONYM_NAME;

2단계: 순환 참조 동의어 탐지 쿼리

-- 동의어가 다른 동의어를 참조하고 있는 경우 탐지
SELECT A.OWNER        AS SYNONYM_OWNER,
       A.SYNONYM_NAME AS SYNONYM_NAME,
       A.TABLE_OWNER  AS POINTS_TO_OWNER,
       A.TABLE_NAME   AS POINTS_TO_SYNONYM,
       B.TABLE_OWNER  AS FINAL_OWNER,
       B.TABLE_NAME   AS FINAL_OBJECT
FROM DBA_SYNONYMS A
JOIN DBA_SYNONYMS B
  ON A.TABLE_NAME  = B.SYNONYM_NAME
 AND A.TABLE_OWNER = B.OWNER
WHERE A.TABLE_NAME IN (SELECT SYNONYM_NAME FROM DBA_SYNONYMS)
ORDER BY A.OWNER, A.SYNONYM_NAME;

3단계: 순환 참조 동의어 제거 및 재생성

-- 문제가 되는 동의어 삭제
DROP SYNONYM SYN_A;
DROP SYNONYM SYN_B;

-- 또는 PUBLIC SYNONYM인 경우
DROP PUBLIC SYNONYM SYN_A;
DROP PUBLIC SYNONYM SYN_B;

-- 원본 객체를 직접 가리키도록 동의어 재생성
CREATE OR REPLACE SYNONYM SYN_A FOR SCHEMA_OWNER.ACTUAL_TABLE_NAME;
CREATE OR REPLACE SYNONYM SYN_B FOR SCHEMA_OWNER.ANOTHER_TABLE_NAME;

-- 재생성 후 동의어 유효성 검증
SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME
FROM USER_SYNONYMS
WHERE SYNONYM_NAME IN ('SYN_A', 'SYN_B');

4단계: 깨진 동의어(Invalid Synonym) 일괄 점검

-- 동의어가 가리키는 객체가 실제로 존재하는지 확인
SELECT S.OWNER,
       S.SYNONYM_NAME,
       S.TABLE_OWNER,
       S.TABLE_NAME,
       CASE
           WHEN O.OBJECT_NAME IS NULL THEN 'INVALID - Object Not Found'
           ELSE 'VALID'
       END AS STATUS
FROM DBA_SYNONYMS S
LEFT JOIN DBA_OBJECTS O
  ON S.TABLE_NAME  = O.OBJECT_NAME
 AND S.TABLE_OWNER = O.OWNER
WHERE S.OWNER = 'YOUR_SCHEMA'  -- 조회할 스키마명 입력
ORDER BY STATUS, S.SYNONYM_NAME;

-- 깨진 동의어 목록만 추출
SELECT S.OWNER, S.SYNONYM_NAME, S.TABLE_OWNER, S.TABLE_NAME
FROM DBA_SYNONYMS S
LEFT JOIN DBA_OBJECTS O
  ON S.TABLE_NAME  = O.OBJECT_NAME
 AND S.TABLE_OWNER = O.OWNER
WHERE O.OBJECT_NAME IS NULL
  AND S.OWNER != 'PUBLIC';

5단계: 동의어 체인 전체 추적 (계층 쿼리 활용)

-- CONNECT BY를 활용한 동의어 체인 추적
SELECT LEVEL,
       LPAD(' ', (LEVEL-1)*4) || SYNONYM_NAME AS CHAIN_PATH,
       TABLE_OWNER,
       TABLE_NAME
FROM DBA_SYNONYMS
START WITH SYNONYM_NAME = 'SYN_A'   -- 추적 시작 동의어명
CONNECT BY PRIOR TABLE_NAME = SYNONYM_NAME
       AND PRIOR TABLE_OWNER = OWNER;

예방 방법

동의어 생성 전 의존성 사전 검증 절차 수립

동의어를 신규 생성하거나 변경하기 전에 반드시 대상 객체가 실제로 존재하는지, 그리고 이미 동의어 체인이 형성되어 있지는 않은지를 사전에 확인하는 검증 스크립트를 배포 프로세스에 포함시켜야 합니다. CI/CD 파이프라인이나 배포 스크립트에 아래와 같은 검증 로직을 추가하여 순환 참조 가능성이 있는 동의어 생성을 원천 차단하는 것이 Best Practice입니다.

“`sql

— 배포 전 동의어 대상 객체 존재 여부 사전 확인

SELECT COUNT(*) AS OBJ_COUNT

FROM DBA_OBJECTS

WHERE OBJECT_NAME = ‘ACTUAL_TABLE_NAME’

AND OWNER = ‘SCHEMA_OWNER’

AND OBJECT_TYPE NOT IN (‘SYNONYM’); — 동의어가 아닌 실제 객체인지 확인

— 결과가 0이면 동의어 생성 중단

“`

정기적인 동의어 상태 모니터링 및 감사(Audit) 체계 구축

운영 환경에서는 주기적(주 1회 이상)으로 전체 동의어의 유효성을 점검하는 모니터링 Job을 Oracle Scheduler를 통해 운영하고, 결과를 DBA팀에 자동 리포팅하는 체계를 구축해야 합니다. 또한 AUDIT CREATE SYNONYM, AUDIT DROP SYNONYM 명령을 활성화하여 누가 언제 동의어를 생성하거나 삭제했는지 추적할 수 있도록 해야 합니다.

“`sql

— Oracle Audit 설정 (동의어 DDL 추적)

AUDIT CREATE SYNONYM BY ACCESS;

AUDIT DROP SYNONYM BY ACCESS;

— 감사 로그 확인

SELECT OS_USERNAME, USERNAME, TIMESTAMP, ACTION_NAME, OBJ_NAME

FROM DBA_AUDIT_TRAIL

WHERE ACTION_NAME IN (‘CREATE SYNONYM’, ‘DROP SYNONYM’)

ORDER BY TIMESTAMP DESC;

“`