반응형
반응형
SPLIT 수행 시 ORA-600 발생 원인과 점검 절차 ORA-600(Internal error)은 “원인 코드/인자(argument)”에 따라 성격이 크게 달라집니다. 특히 파티션 SPLIT 같은 DDL 작업 중 ORA-600이 뜨면, (1) 오브젝트/인덱스/UNDO/시스템 상태 문제인지, (2) 특정 버전 결함(버그)인지부터 빠르게 갈라서 보는 게 핵심입니다. 먼저 결론부터 - ORA-600은 “코드(첫 번째 argument) + trace/alert”가 없으면 정답을 못 좁힙니다. - 운영 환경에서는 “재현/우회”보다 원인 코드 확보 → 영향 범위 확정 → 안전한 복구 루트가 우선입니다. ..
ORA-01210 데이터파일 헤더 미디어 손상으로 RECOVER 실패 시 복구 절차 아래 내용은 RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL 수행 중 ORA-01210(data file header is media corrupt)로 복구 세션이 중단되는 케이스를 기준으로 정리했습니다. 개요 다음과 같은 로그 흐름은 “아카이브/리두 부족”이 아니라, 특정 데이터파일의 헤더 자체가 물리적으로 손상되어 검증 단계에서 복구가 끊기는 패턴입니다. S..
Rescue 모드에서 인증 장애 복구: /etc/shadow·unix_chkpwd·init 실행 실패 점검 권한/보안 점검 조치 이후 로그인 불가 또는 /sbin/init 실행 실패까지 번질 때, 단계별로 원인 분기와 복구를 진행합니다. 개요 사용자 인증 체계(PAM)는 /etc/shadow를 일반 사용자에게 직접 노출하지 않도록 설계되어 있고, 대신 인증 과정에서 필요한 접근을 unix_chkpwd 같은 헬퍼가 담당합니다. 여기서 권한(특히 SUID)이나 파일 접근이 끊기면 SSH, sudo, su가 연쇄로 실패해 ..
리눅스 커널 로그에서 SYN 반복 유입 확인과 대응 절차 커널 로그에 특정 포트로 TCP SYN 패킷이 짧은 시간에 반복 기록되는 경우는 흔히 포트 스캔, 오탐(정상 헬스체크/클라이언트 재시도), 또는 SYN Flood 성격의 비정상 트래픽으로 나뉩니다. 실제 사용 시에는 “차단했나/허용했나”보다 먼저, 해당 포트의 서비스 노출 여부와 연결 성립(3-way handshake) 여부를 구분해서 보는 게 핵심입니다. 핵심 포인트: SYN 반복 = 공격 단정 금지 우선순위: 노출 여부 → 연결 성립 여부 → 발생 원인 대응: ..
리눅스 SWAP 확인부터 스왑 메모리 증설까지 서버에서 메모리가 부족해지면 커널이 디스크 기반의 SWAP을 사용하면서 응답이 급격히 느려질 수 있습니다. 이 문서는 현재 SWAP 상태 확인부터 원인 점검, 그리고 스왑 파일/스왑 파티션 증설 및 영구 적용까지 한 흐름으로 정리합니다. 개요 SWAP을 늘리는 건 “메모리 부족 상황에서 서버가 죽는 것”을 막는 완충 장치입니다. 다만 SWAP이 많다고 성능이 좋아지는 건 아니고, SWAP 사용이 잦다면 메모리 누수/캐시 정책/프로세스 튜닝이 우선입니다. ..
오라클에서 AP/WAS 접속 서비스 식별하는 방법 데이터베이스에 붙는 AP/WAS(애플리케이션 서버)나 배치, 도구 접속을 구분하려면 세션 메타데이터를 보는 게 가장 빠릅니다. 핵심은 “DB가 아는 정보(서버/프로그램/앱이 넘겨준 모듈)”를 조합해서 어떤 서비스가 붙었는지 실무적으로 식별하는 것입니다. 개요 오라클 DB는 기본적으로 “정확히 어떤 WAS 서비스인지”를 100% 자동 판별하진 못합니다. 대신 아래 컬럼 조합으로 거의 실무 수준의 식별이 가능합니다. ..