상황 개요

테스트 환경에서 OracleTextSearch(이하 OTS)를 사용하던 중, DB 복사 직후 검색 서비스에서 시간 초과와 정렬 오류가 보고되었습니다. 특히 OTS를 비활성화하고 DB-path로 검색을 수행할 때 일부 쿼리에서 정렬 지정 값(SortSpec)이 거절되어 결과가 반환되지 않았습니다. 반면 동일 조건에서 관리자 권한 계정(예: weblogic)은 정상 동작하고, 일반 사용자에게만 실패가 발생하는 패턴이 관찰되어 원인 분석이 필요했습니다.

증상과 로그 (주석 포함)

1) DB-path에서 SortSpec 거절

Caused By: intradoc.data.DataException: !csSearchInvalidOrderByClause,dDocTitle ASC
# 의미: DB-path가 전달받은 SortSpec 값이 "완전한 ORDER BY 구문"이 아니라고 판단하여 거절

Caused By: intradoc.data.DataException: !csSearchInvalidOrderByClause,xPublishDate DESC\, sddDocTitle ASC
# 의미: 쉼표 앞 역슬래시(\)나 화면 별칭 사용 등으로 인해 구문 검증 실패

2) OTS 사용 시 시간 초과/확장 초과 의심

ORA-01013: 사용자가 현재 작업의 취소를 요청했습니다
# 의미: 서버 측에서 쿼리가 취소됨(타임아웃/사용자 취소/리소스 제한 등으로 중단)

DRG-51030: wildcard query expansion resulted in too many terms
# 의미: 와일드카드 확장(패턴 매칭으로 실제 검색어 목록을 만들어내는 과정)에서 항목 수가 한도를 초과

원인 진단

문제는 DB-path와 OTS 두 경로에서 각각 다르게 드러났습니다. DB-path에서는 서버 측 정렬 구문 검증이 활성화되어 있었고, SortSpec 값이 완전한 ORDER BY 문법(예: order by col1 DESC, col2 ASC)을 따르지 않거나 화면 별칭/역슬래시가 포함되면 검색 서비스가 결과를 반환하지 않았습니다. OTS 경로에서는 DB 복사 직후 컬렉션과 인덱스의 메타 상태가 어긋나 있을 가능성과, 일반 사용자에 한해 보안 필터가 결합된 조건에서 와일드카드 확장 항목 수가 급격히 늘어나는 상황이 의심되었습니다.

조치 ①: DB-path의 SortSpec 교정

먼저 DB-path에서 오류를 유발한 스크립트를 수정해 동일 조건으로 재시험했습니다. 핵심은 완전한 ORDER BY 구문을 사용하고, 화면 별칭 대신 실제 컬럼명을 지정하며, 역슬래시( \ )를 제거하는 것입니다. 수정 후 테스트는 즉시 정상 완료되었습니다.

@Properties LocalData
IdcService=GET_SEARCH_RESULTS
UserTimeZone=UTC
QueryText=... (생략)
SortSpec=dDocTitle ASC               # ← <-- 완전한 ORDER BY 구문이 아님
ResultCount=10
StartRow=1
@end

@Properties LocalData
IdcService=GET_SEARCH_RESULTS
UserTimeZone=UTC
QueryText=... (생략)
SortSpec=order by xPublishDate DESC, dDocTitle ASC  # 완전한 ORDER BY + 쉼표 사용
ResultCount=10
StartRow=1
@end

조치 ②: DB 복사 후 OTS 재구성

DB 복사 직후에는 OTS 컬렉션과 DB 객체 사이의 상태가 일시적으로 어긋날 수 있습니다. OTS를 활성화한 뒤 컬렉션 재구축(Collection Rebuild)을 1회 수행하고, WORDLIST 속성을 반영한 다음 관련 인덱스를 온라인 재구축하는 순서로 정리했습니다.

1) Collection Rebuild 1회

WCC 관리자 콘솔에서 Administration → Repository Manager → Indexer(버전에 따라 “Search Index/Collections”)로 이동해 Rebuild Entire Index를 1회 실행합니다. 실행 전 SearchIndexerEngineName=OracleTextSearch가 활성인지(또는 config.cfg의 Additional Configuration) 확인합니다. 부하를 줄이기 위해 가급적 저부하 시간대에 수행합니다.

2) WORDLIST 속성 반영 (이름 변경 포함)

예시 WORDLIST 이름으로 DOC_WORDLIST를 사용하고, 와일드카드 확장 항목 수는 합의 값(예: 25,000~50,000)으로 단계적으로 조정합니다.

BEGIN
  CTX_DDL.SET_ATTRIBUTE('DOC_WORDLIST', 'WILDCARD_MAXTERMS', '25000'); 
  -- 의미: 와일드카드 확장 항목 수 상한을 25,000으로 설정(필요 시 점진 상향)
END;
/

3) 관련 인덱스 온라인 재구축 (이름 변경 포함)

고객 구성을 노출하지 않기 위해, 본 글에서는 인덱스명을 IDX_DOCTEXT_A, IDX_DOCTEXT_B로 표기합니다(스키마 예: APP_SCHEMA).

ALTER INDEX APP_SCHEMA.IDX_DOCTEXT_A 
  REBUILD ONLINE PARAMETERS('REPLACE WORDLIST DOC_WORDLIST');

ALTER INDEX APP_SCHEMA.IDX_DOCTEXT_B 
  REBUILD ONLINE PARAMETERS('REPLACE WORDLIST DOC_WORDLIST');

4) 적용 확인

SELECT CTX_REPORT.DESCRIBE_INDEX('APP_SCHEMA.IDX_DOCTEXT_A') FROM dual;
SELECT CTX_REPORT.DESCRIBE_INDEX('APP_SCHEMA.IDX_DOCTEXT_B') FROM dual;
-- 의미: WORDLIST/LEXER 등 속성들이 실제 인덱스에 반영되었는지 확인

조치 ③: 관리자(webLogic) 정상·일반 사용자만 실패하는 경우

OTS를 사용하는 환경에서 관리자 계정은 정상인데 일반 사용자만 느리거나 실패한다면, 계정 보안 필터(ACL/Account/Group)가 쿼리에 결합되면서 와일드카드 확장 항목 수가 크게 증가하는 패턴을 의심할 수 있습니다. 이때는 다음 순서로 개선을 진행합니다.

1. 보안 컬럼의 SDATA 최적화 적용
   Configuration Manager → Search → Fields에서 보안 필드(예: dDocAccount)에 Is Optimized(SDATA)를 적용합니다. 이는 보안 필터 결합 시 조건 평가를 가볍게 해줍니다.
2. 와일드카드 사용 범위 점검
   일반 사용자 프로필에서 과도한 접두/접미 와일드카드(*term*) 사용을 제한하고, 필요 시 DOC_WORDLIST.WILDCARD_MAXTERMS를 점진 상향(예: 25,000 → 35,000 → 50,000)하며 부하를 관찰합니다.
3. 타임아웃/리소스 파라미터 점검
   애플리케이션/DB 쿼리 제한(예: JDBC 타임아웃, 세션 레벨 리소스 한도)을 확인해 ORA-01013이 조기에 발생하지 않도록 합니다.

검증 결과와 운영 반영

먼저 DB-path 경로에서 스크립트의 SortSpec만 교정해 재시험한 결과, 서비스가 정상적으로 완료됨을 확인했습니다. 이후 동일한 정렬 형식을 WCC 설정에도 반영하여 화면 검색이 문제없이 수행되는 것을 재확인했고, 최종적으로 운영 환경에 동일 구성을 적용해 마무리했습니다.

한편 OTS 경로의 재구성(컬렉션 재구축 및 WORDLIST/인덱스 재바인딩)은 테스트 환경에서 사전 검증을 마쳤으며, 일반 사용자 관점의 성능·안정성 개선을 위해 보안 필드 SDATA 최적화와 와일드카드 파라미터 튜닝을 추가 시나리오로 준비했습니다. 해당 검증은 별도의 일정으로 진행하며, 결과는 후속 포스팅으로 공유하겠습니다.

체크리스트

• DB-path에서는 SortSpec=order by ... 완전 구문을 사용한다(쉼표 포함, 별칭/역슬래시 금지).
• DB 복사 직후 OTS는 Collection Rebuild → WORDLIST 반영 → 인덱스 온라인 재구축 순서로 정리한다.
• 와일드카드 확장 항목 수는 DOC_WORDLIST.WILDCARD_MAXTERMS로 단계 튜닝한다(필요 시 50,000까지).
• 일반 사용자만 느리거나 실패하면 보안 컬럼에 SDATA 최적화를 우선 적용한다.
• 운영 반영 전, 동일 설정으로 UI 검색까지 엔드-투-엔드 재확인 후 릴리스한다.

부록: 참고 스니펫

-- WORDLIST 속성 반영(예: 25,000)
BEGIN
  CTX_DDL.SET_ATTRIBUTE('DOC_WORDLIST', 'WILDCARD_MAXTERMS', '25000');
END;
/

-- 인덱스 온라인 재구축 (WORDLIST 재바인딩)
ALTER INDEX APP_SCHEMA.IDX_DOCTEXT_A 
  REBUILD ONLINE PARAMETERS('REPLACE WORDLIST DOC_WORDLIST');

ALTER INDEX APP_SCHEMA.IDX_DOCTEXT_B 
  REBUILD ONLINE PARAMETERS('REPLACE WORDLIST DOC_WORDLIST');

-- 인덱스 기술 정보 확인
SELECT CTX_REPORT.DESCRIBE_INDEX('APP_SCHEMA.IDX_DOCTEXT_A') FROM dual;
SELECT CTX_REPORT.DESCRIBE_INDEX('APP_SCHEMA.IDX_DOCTEXT_B') FROM dual;

@Properties LocalData
IdcService=GET_SEARCH_RESULTS
UserTimeZone=UTC
QueryText=(... 생략 ...) <AND> dDocTitle <substring> <qsch>테스트</qsch>
SortSpec=order by xPublishDate DESC, dDocTitle ASC
ResultCount=10
StartRow=1
@end