디렉터리와 파일 관리

#핵심 요약

파일 관리 실습은 cd로 작업 위치를 정하고 mkdir, touch로 준비한 뒤 cp, mv, rm을 다루는 순서임

복사, 이동, 삭제 전에는 와일드카드가 어떤 파일로 펼쳐지는지 ls나 echo로 먼저 확인함

파일 수정 시각(mtime)은 백업 검증, 장애 추적, 증분 처리의 판단 근거라 복사할 때 cp -p, rsync -a, scp -p로 보존하는 것이 우선임

mv로 이름만 바꾸면 inode가 그대로라, 열린 로그 파일을 옮겨도 프로세스는 옛 파일에 계속 씀

#개념과 동작 원리

mtime이 중요한 이유: scp나 옵션 없는 cp는 mtime을 복사 시각으로 바꿈
그러면 소스와 사본이 같은 파일인지 시각으로 판단할 수 없고, 여러 노드의 로그를 모을 때 장애 시각을 파일 시각으로 거슬러 찾기 어려워짐
rsync, make, tar 증분 백업은 "소스가 더 새로우면 다시 처리"하는 식으로 mtime을 비교하므로 시각이 엉키면 바뀐 파일을 건너뛰거나 안 바뀐 파일을 계속 다시 처리함
touch -r은 이미 시각이 깨졌거나 시험용 파일에 일부러 시각을 줄 때 쓰는 보조 수단임

#필수 명령어 또는 SQL

#자주 가는 경로와 alert 로그 시각

alias net2='cd $ORACLE_HOME/network/admin'
ls -l --time-style=long-iso alert*
echo 'export TIME_STYLE=long-iso' >> ~/.bash_profile
source ~/.bash_profile

결과 해석:

listener.ora가 있는 $ORACLE_HOME/network/admin으로 바로 가는 별칭을 net2로 만드는 과제임
영구히 쓰려면 별칭도 .bash_profile에 넣음

실습 기록: alert 로그를 연 상태에서 DB를 내렸다 올리자 ls -l 시각이 10:15에서 11:21로, 크기가 287782에서 305475바이트로 바뀜

TIME_STYLE=long-iso를 두면 ls -l이 매번 2026-07-09 10:15 형식으로 시각을 보여 줌

#빈 파일과 시각 지정

touch practice1.log
ls -l practice1.log
touch -t 202607090900 base.log
touch new.log
touch -r base.log new.log
ls -l base.log new.log

결과 해석:

같은 touch를 다시 실행하면 내용은 그대로 두고 수정 시각만 갱신됨

-t의 형식은 [[CC]YY]MMDDhhmm[.ss]이며 위 예는 2026년 7월 9일 09:00임

시각을 같게 맞춘 것은 내용이 같다는 증명이 아니므로 내용 비교는 체크섬이나 diff로 함

#디렉터리 만들기

mkdir work
mkdir step1
cd step1
mkdir step2
cd ~
mkdir -p project/src/main/java
ls -ld project
mkdir -p backup/2026
mkdir -p app/{conf,log,data}
mkdir -m 700 secure
ls -ld app
find app -type d
mkdir "my backup"
cd "my backup"

mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app/oracle

결과 해석:

ls -ld는 디렉터리 안의 목록이 아니라 디렉터리 자체의 권한, 소유자를 보여 줌

mkdir -p backup/2026은 이미 있으면 오류 없이 넘어가 스크립트에 넣기 좋음

app/{conf,log,data}는 셸의 중괄호 확장이라 mkdir에는 세 경로가 따로 넘어감

공백이 든 이름은 따옴표로 묶어야 한 이름으로 처리됨

oracle 계정으로 mkdir /root/test가 Permission denied로 끝나는 것은 /root에 쓰기 권한이 없기 때문임

#복사와 날짜 붙인 백업

mkdir backup
ls -l *.csv
cp *.csv ./backup/

mkdir -p net_cfg_lab/conf net_cfg_lab/backup net_cfg_lab/logs net_cfg_lab/restore
today=$(date +%Y%m%d)
echo $today
cp net_cfg_lab/conf/listener.ora net_cfg_lab/backup/listener.ora.$today

ls net_cfg_lab/logs
cp net_cfg_lab/logs/*.log net_cfg_lab/restore/
ls -l net_cfg_lab/restore/

결과 해석:

$(date +%Y%m%d)는 명령 출력을 변수에 담는 형태이며, 2026년 7월 16일이면 20260716이 됨

설정 파일을 고치기 전에는 날짜를 붙여 백업함

실습 기록: logs의 alert_orcl1.log, alert_orcl2.log, listener.trc 가운데 .log 두 개만 restore로 복사됨

수업 자료에는 DB를 정상 종료한 뒤 데이터 파일, 컨트롤 파일, 리두 로그가 든 oradata/ORCL을 cp -r이나 cp -a로 통째로 복사하는 과제도 있음
DB가 열린 상태에서 파일을 복사한 것은 일관된 백업이 아니므로 반드시 정상 종료 뒤에 하고, 실제 백업은 RMAN을 씀

#이동, 이름 변경, 여러 파일 이동

grep -l "ORA-07445" incident/*.trc
mv incident/orcl_ora_20481.trc mos_upload/SR30110234_orcl_ora_20481.trc

ls work/*.sql
mv -t release work/*.sql
ls release | wc -l
ls work

mkdir -p fra/archivelog/2026_05 fra/archivelog/2026_06
ls fra/archivelog/*202605*.arc
mv fra/archivelog/*202605*.arc fra/archivelog/2026_05/
ls fra/archivelog/*202606*.arc
mv fra/archivelog/*202606*.arc fra/archivelog/2026_06/
find fra -name "*.arc" | wc -l
ls fra/archivelog/2026_05 | wc -l

mv -v adump/orcl_ora_501.aud adump/orcl_ora_502.aud adump_old/ >> move_audit.log
mv -v adump/orcl_ora_601.aud adump_old/ >> move_audit.log
cat move_audit.log
grep 601 move_audit.log
wc -l move_audit.log
ls adump_old | wc -l

결과 해석:

목적지 경로에 새 이름까지 쓰면 한 번의 mv로 이동과 이름 변경이 같이 됨
SR 업로드 예는 grep -l로 ORA-07445가 든 파일만 먼저 골라냄

mv -t release처럼 목적지를 앞에 두면 자동화 스크립트에서 인자 순서를 바꿔 쓰는 실수를 막음
*.sql만 옮기므로 work에는 draft_memo.txt가 남아야 함

와일드카드 mv는 실행 전에 같은 패턴으로 ls해 대상 수를 확인하고, 실행 뒤에는 전체 개수가 그대로인지(분실 없음) 다시 셈

mv -v 출력을 >>로 쌓아 두면 "그 파일이 어디 갔는지" 나중에 추적할 수 있고, 기록 줄 수와 실제 이동 파일 수를 비교해 검증함

#열린 로그 파일과 mv (로그 로테이션)

ls -il alert*
mv alert_ORCL2.log alert_ORCL2_20260716.log
# SQL*Plus에서 DB를 내렸다 올린 뒤
ls -il alert*

결과 해석:

실습 기록: 이름을 바꾼 alert_ORCL2_20260716.log는 원래 inode 536873390을 그대로 가졌고, DB 재기동 뒤 새 alert_ORCL2.log가 다른 inode 537046477로 생김

mv는 같은 파일 시스템 안에서 디렉터리 항목의 이름만 바꾸므로, 파일을 열고 있던 프로세스는 이름이 바뀐 옛 파일에 계속 씀
로그를 돌린 뒤에는 그 프로세스가 파일을 다시 열게 해야 새 파일에 기록됨

실습은 shutdown abort로 재기동했지만 운영에서 로그 로테이션 때문에 인스턴스를 강제 종료하지는 않음

#설정 파일 원복과 교체

mv dbs/initORCL.ora dbs/initORCL.ora.bad
cp -p backup/initORCL.ora.20260715 dbs/initORCL.ora
grep processes dbs/initORCL.ora
ls dbs backup
diff dbs/initORCL.ora.bad dbs/initORCL.ora

cp -p admin/listener.ora backup/listener.ora.premig
sed 's/<OLD_HOST>/<NEW_HOST>/' admin/listener.ora > admin/listener.ora.new
diff admin/listener.ora admin/listener.ora.new
mv admin/listener.ora.new admin/listener.ora
ls admin
find . -name "listener.ora*"
cat admin/listener.ora

결과 해석:

원복 원칙: 문제 파일은 지우지 않고 .bad로 남겨 원인 증거로 쓰고, 백업본은 mv가 아니라 cp -p로 되돌려 백업을 그대로 둠

교체 순서는 백업 → 새 파일 생성 → diff로 바뀌는 줄 확인 → mv로 교체이며, 운영 파일을 직접 고치지 않음
같은 파일 시스템 안의 mv는 이름을 한 번에 바꾸므로 읽는 쪽이 반쯤 쓴 파일을 보지 않음

예상값: cat admin/listener.ora에 HOST=<NEW_HOST>이 보이고 admin에 .new 파일이 남지 않음

sed의 점(.)은 아무 문자 하나와 맞으므로 정확히 하려면 db-old\.corp\.local처럼 이스케이프함

#삭제 대상 확인과 삭제

echo rm *.csv

rm *.csv
rm -ri oracle1

show homes
set home diag/rdbms/<db_name>/<SID>
show problems
show incident
purge -age 43200 -type TRACE

결과 해석:

echo rm *.csv는 셸이 펼친 대상(rm dept_backup.csv emp_backup.csv)만 보여 주고 지우지 않음

실습 기록: rm *.csv가 파일마다 remove 일반 파일 ...?를 물음
셸에 rm -i 별칭이 걸린 경우의 동작이며 모든 환경에서 묻는 것은 아님

rm -ri는 하위까지 지우면서 항목마다 묻고, rm -rf는 묻지 않으므로 경로를 다시 확인함

find의 -mtime +30은 30일 초과(사실상 31일 이상), -mtime -30은 최근 30일 이내, -mtime 30은 딱 30일 전 하루치임

trace 파일은 OS에서 바로 지우지 않고 adrci로 지우는 것이 안전함
purge -age는 분 단위라 43200은 30일이며, 위치는 V$DIAG_INFO의 Diag Trace로 확인함

#사용 조건과 주의사항

rm에는 휴지통이 없으므로 와일드카드 삭제 전에는 echo나 ls로 대상을 먼저 봄

열린 파일을 rm해도 디스크 공간은 그 파일을 연 프로세스가 닫을 때까지 돌아오지 않음

DB 파일 복사는 DB를 정상 종료한 상태에서만 일관성이 있으며, 열린 DB의 파일을 OS 명령으로 복사하거나 지우지 않음