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

ORA-00942
2026년 06월 21일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-00942 table or view does not exist 는?

ORA-00942 에러는 Oracle 데이터베이스에서 SQL 문장이 참조하는 테이블 또는 뷰가 현재 세션에서 접근 불가능할 때 발생하는 에러입니다. 이 에러는 단순히 객체가 존재하지 않는 경우뿐만 아니라, 객체는 존재하지만 현재 사용자에게 접근 권한이 없는 경우에도 동일하게 발생합니다. 실무에서 매우 빈번하게 마주치는 에러 중 하나로, 개발 환경과 운영 환경 간의 스키마 차이나 권한 설정 누락으로 인해 자주 발생합니다.

주요 발생 원인

1. 테이블 또는 뷰가 실제로 존재하지 않는 경우

가장 흔한 원인으로, 오타나 대소문자 혼동으로 인해 잘못된 객체 이름을 참조하는 경우입니다. Oracle은 기본적으로 객체 이름을 대문자로 저장하기 때문에, 큰따옴표(“)를 사용하여 소문자로 생성된 객체를 대문자로 조회하면 에러가 발생합니다. 또한 개발 DB에는 존재하지만 운영 DB에는 아직 배포되지 않은 테이블을 참조할 때도 이 에러가 나타납니다.

2. 접근 권한(Privilege) 부족

테이블이나 뷰가 실제로 존재하더라도 현재 접속한 사용자에게 해당 객체에 대한 SELECT, INSERT, UPDATE, DELETE 등의 권한이 부여되지 않은 경우 ORA-00942가 발생합니다. Oracle 보안 정책상 권한이 없는 객체는 마치 존재하지 않는 것처럼 에러를 반환하며, 이는 의도적인 설계입니다. 특히 다른 스키마(사용자)의 테이블을 접근할 때 자주 발생하며, Synonym(동의어) 설정이 누락된 경우에도 동일 에러가 발생합니다.

3. 스키마(Schema) 지정 누락 또는 잘못된 지정

다른 사용자 소유의 테이블을 접근할 때 스키마명을 명시하지 않으면 Oracle은 현재 로그인한 사용자의 스키마에서만 객체를 찾습니다. 예를 들어 SCOTT 스키마의 EMP 테이블을 HR 사용자로 접속하여 조회할 때 SELECT FROM EMP 대신 SELECT FROM SCOTT.EMP와 같이 스키마명을 명시해야 합니다. 이 원인은 어플리케이션 계정과 오브젝트 소유 계정이 분리된 실무 환경에서 특히 자주 발생합니다.

해결 방법

원인 1 해결: 객체 존재 여부 확인

먼저 해당 테이블 또는 뷰가 데이터베이스에 실제로 존재하는지 확인합니다.

-- 현재 사용자 소유의 테이블 확인
SELECT table_name, owner
FROM user_tables
WHERE table_name = 'EMP';  -- 반드시 대문자로 조회

-- 데이터베이스 전체에서 테이블 확인 (DBA 권한 필요)
SELECT owner, object_name, object_type, status
FROM dba_objects
WHERE object_name = 'EMP'
  AND object_type IN ('TABLE', 'VIEW', 'SYNONYM');

-- 모든 접근 가능한 객체에서 확인 (일반 사용자)
SELECT owner, object_name, object_type
FROM all_objects
WHERE object_name = 'EMP'
  AND object_type IN ('TABLE', 'VIEW');

원인 2 해결: 권한 부여

권한이 없는 경우 DBA 또는 객체 소유자가 권한을 부여해야 합니다.

-- 특정 사용자에게 테이블 SELECT 권한 부여 (객체 소유자 또는 DBA 실행)
GRANT SELECT ON scott.emp TO hr_user;

-- 여러 권한 동시 부여
GRANT SELECT, INSERT, UPDATE, DELETE ON scott.emp TO hr_user;

-- 모든 사용자에게 권한 부여 (보안 주의)
GRANT SELECT ON scott.emp TO PUBLIC;

-- 현재 사용자가 접근 가능한 테이블 권한 확인
SELECT grantee, owner, table_name, privilege, grantable
FROM all_tab_privs
WHERE table_name = 'EMP'
  AND grantee = 'HR_USER';

-- Synonym(동의어) 생성으로 스키마명 없이 접근 가능하게 설정
CREATE SYNONYM emp FOR scott.emp;

-- 공용 Synonym 생성 (DBA 권한 필요)
CREATE PUBLIC SYNONYM emp FOR scott.emp;

원인 3 해결: 스키마명 명시 및 현재 스키마 변경

-- 스키마명을 명시하여 다른 스키마의 테이블 접근
SELECT * FROM scott.emp;
SELECT * FROM scott.dept d JOIN scott.emp e ON d.deptno = e.deptno;

-- 현재 세션의 스키마를 변경하여 접근 (편의성 향상)
ALTER SESSION SET CURRENT_SCHEMA = scott;

-- 변경 후에는 스키마명 없이 접근 가능
SELECT * FROM emp;

-- 현재 세션의 스키마 확인
SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') AS current_schema FROM dual;

추가 진단 쿼리: 에러 발생 시 빠른 점검

-- 접근 가능한 모든 테이블에서 이름으로 검색 (오타 확인용)
SELECT owner, table_name
FROM all_tables
WHERE table_name LIKE '%EMP%'
ORDER BY owner, table_name;

-- 뷰 존재 여부 확인
SELECT owner, view_name, status
FROM all_views
WHERE view_name = 'EMP_VIEW';

-- Synonym 확인
SELECT synonym_name, table_owner, table_name
FROM all_synonyms
WHERE synonym_name = 'EMP';

-- 사용자에게 부여된 시스템 권한 확인
SELECT privilege
FROM user_sys_privs
WHERE privilege LIKE '%ANY TABLE%';

예방 방법

1. 배포 스크립트에 권한 부여 구문 포함 및 접근 권한 체계 표준화

테이블 생성 DDL 스크립트와 함께 권한 부여(GRANT) 구문을 항상 패키지로 관리하고, 신규 객체 생성 시 권한 부여 및 Synonym 생성까지 자동화된 체크리스트를 운용하는 것이 중요합니다. 또한 어플리케이션 계정별 접근 가능한 객체 목록을 문서화하고, 정기적으로 all_tab_privs 뷰를 통해 권한 현황을 감사(Audit)하는 프로세스를 도입하면 권한 누락으로 인한 에러를 사전에 방지할 수 있습니다.

2. 개발/운영 환경 간 스키마 동기화 관리 및 객체 명명 규칙 준수

DDL 변경 이력을 형상 관리 도구(Git 등)로 관리하고, 개발 환경과 운영 환경 간 스키마 차이를 주기적으로 비교·동기화하는 프로세스를 정착시켜야 합니다. Oracle의 DBMS_METADATA 패키지나 서드파티 스키마 비교 도구를 활용하면 환경 간 객체 불일치를 빠르게 감지할 수 있으며, 객체 이름은 항상 대문자로 통일하고 큰따옴표를 사용한 소문자 객체 생성을 금지하는 명명 규칙을 팀 전체가 준수하도록 교육하는 것이 좋습니다.