YuMa의 DB 이야기

-- DB status reset 
EXEC sp_resetstatus 'DB명'

-- 응급 상태로 전환
ALTER DATABASE DB명 SET EMERGENCY

--DBCC 수행
DBCC checkdb(' DB명 ')

--싱글 유저로 바꿔서 접근 제한
ALTER DATABASE DB명 SET single_user WITH ROLLBACK IMMEDIATE

-- DB REPAIR
DBCC checkdb(' DB명 ', 옵션)

* REPAIR 옵션

1) REPAIR_FAST : 시간이 많이 소요되지않고, 데이터의 손실이 없는 사소한 오류를 수정 (클러스터되지 않은 인덱스 복구 가능)
2) REPAIR_REBUILD : REPAIR_FAST이 하는 모든 작업, 인덱스 재생성과 같이 시간이 소요되는 작업이 복구 과정에서 진행됨. 역시 데이터의 손실 위험은 없다.
3) REPAIR_ALLOW_DATA_LOSS : REPAIR_REBUILD이 하는 모든 작업, 할당 오류, 구조적 행 오류나 페이지 오류, 손상된 텍스트 개체 삭제를 수정하기 위한 행과 페이징의 할당 및 할당 취소 등의 작업이 행해진다.

-- 멀티 유저로 바꾸기
ALTER DATABASE DB명 SET MULTI_USER

find . -size 0c -delete

출처 : https://juggernaut.tistory.com/m/130

Oracle Alert log 점검중 확인한 경고 메시지.

Mon Mar 25 10:13:01 2024
Warning: VKTM detected a time drift.
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file for more details.

OS와 DB상의 시간이 맞지 않을 경우 나타난다고 하는데,

읭? OS와 DB는 시간이 맞는거 같은데??

1. DB

> select to_char(sysdate, 'yyyymmdd hh24:mi:ss') from dual;

TO_CHAR(SYSDATE,'
-----------------
20240325 15:39:40

2. OS (Linux)
# date
Mon Mar 25 15:39:44 KST 2024

>> 동시에 친게 아니라 순차적으로 친거라 몇초의 시간차는 있음.;;

뭐지뭐지 하다가 구글링해서 얻은 결과.

 하드웨어의 시간을 확인하라.

# hwclock
Mon Mar 25 14:17:00 2024  -0.250758 seconds

시간 차이가 한시간 이상 나잖아;;;

rdate로 OS와 HW의 시간을 동기화 해야한다.

하지만 쫄보는 바로 적용하지 않지.

PM 일정 잡아서 다른거랑 한번에 작업하자.

<<해결방법>>

1. rdate 설치
  <CentOS>
# yum -y install rdate
  <Ubuntu>
# apt-get -y install rdate
​
2. 시간 동기화
# rdate -s time.bora.net && hwclock -w

참고 : https://blog.naver.com/lgc2015/223311995308

20250716 추가

아니 사실 그전에, 요즘 시대에 rdate 를 쓴다는 것이 말이 되는가,

NTP나 Chrony 로 시간 동기화 방법을 변경하는게 맞다.

rdate 로 한방에 시간을 맞출라고 하니 이 사단이 나는거다!!

(테스트 서버에서 rdate 사용시에는 동일하게 VKTM warning 이 발생하였으나, Chrony 로 변경한 후에는 더이상 발생하지 않았다.)