0131 ADMIN

0131
어제 내용 복습

아키텍쳐가 머리속에 있어야 해.

메모리 - 컴퓨터 끄면 사라짐.

instance
shared pool
sga
db buffer cache 데이터 군락을 올려놓음 변경된 버퍼 더티버퍼 dbwr 가 내려 씀.
redo log buffer 변경사항 기록을 해놓음 -- 변경사항들 수시로 내려 쓰는데 로그라이터가 리드로그파일로 내려 씀.

sql 실행계획 파싱과정 생략하려고 공유 풀에다가 올려놓는다
백그라운드 프로세서
pmon
DBWR 변경된 버퍼 더티버퍼 dbwr 가 내려 씀.
LGWR 로그라이터가 리드로그파일로 내려 씀.
ckpt 체크포인트 프로세서가 혹시 몰라서 놀고있을 까봐 이벤트를 일으키라고 주문을 한다.

DB 에는
data file redolog file 있음.

▩ 18. PMON 프로세서 (Process monitor)

클라이언트 -------------------------- > 서버

서버에서 돌았던 작업들을 모두 rollback

2. 아무것고 안하고 놀고있으면 그 세션을 끊어버리는 역할

   ※ 오라클 12c 버젼부터 리스너에 서비스를 자동으로 등록해주는 기능이
   pmon 이 아니라 LPEG(Listener Registration) 프로세서가 담당 합니다.

[orcl:product]$ cd /u01/app/oracle/product/11.2.0
[orcl:11.2.0]$ pwd
/u01/app/oracle/product/11.2.0
[orcl:11.2.0]$ ls
dbhome_1 grid

그리드 ? listener.ora

oracle 홈디렉토리 (식당)
grid 홈디렉토리 (건물)

[orcl:grid]$ cd netowork
-bash: cd: netowork: 그런 파일이나 디렉토리가 없음
[orcl:grid]$ cd network
[orcl:network]$ ls
admin doc install jlib lib log mesg tools trace
[orcl:network]$ cd admin
[orcl:admin]$ ls
listener.ora listener.ora.bak.edydr1p0 samples shrept.lst sqlnet.ora

[orcl:admin]$ cat listener.ora

listener.ora Network Configuration File: /u01/app/oracle/product/11.2.0/grid/network/admin/listener.ora

Generated by Oracle configuration tools.

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = edydr1p0.us.oracle.com)(PORT = 1521))
)
)

ADR_BASE_LISTENER = /u01/app/oracle

ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent

▲ 위의 내용을 보면 포트, 호스트, 프로토콜은 있는데 서비스 이름이 없다.

이 서비스 이름이 없는데 어떻게 listener 가 서비스 이름을 알 수 있는가 ?

리스너에 서비스를 등록하는 방법 2가지

1. 정적 서비스 등록 : 4가지 정보를 listener.ora 에 전부 구성하는 것
2. 동적 서비스 등록 : 3가지 정보만 listener.ora 에 가지고 있고 서비스 이름은
   LPEG 프로세서가 listener 에게 등록해주는 방식이다.

클라이언트 ------------------- > 서버
4가지 정보 접속성공 리스너가 네가지 정보를 알고 있어야

listener.ora Network Configuration File: C:\app\itwill\product\11.2.0\dbhome_1\network\admin\listener.ora

Generated by Oracle configuration tools.

실습 : 동적 서비스 등록방식일 때의 오라클 접속 방법 테스트

#1. 서버에서 리스너를 내립니다.
$ lsnrctl stop

#2. 리스너를 올립니다.
$ lsnrctl start

#3. 리스너의 상태를 확인합니다.

$ lsnrctl status

4. 자기 서버의 db 에 리스너를 통해서 접속해 봅시다 !

sqlplus scott/tiger@192.168.19.43:1521/orcl.us.oracle.com

5. 나의 리스너를 내리고 다시 리스너를 통해서 접속 되는지 확인하시오 !

lsnrctl stop

안들어가짐
dbever 도 안들어가짐.

6. 리스너를 다시 올리고 접속 되는지 확인하시오

lsnrctl start

ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor

에러남

좀 기다리면 된다

문제1. 짝 자리로 리스너 통해서 접속해보시오 ~
sqlplus scott/tiger@192.168.19.45:1521/orcl.us.oracle.com

▩ 19. 복구자 프로세서 (RECO : recovery process)

In - Doubt 의심스러운 세션 - RECO 가 떠서 정리해줌

reco 가 이 프로세서를 자동으로 정리를 못하면 문제가 생깁니다.

그 문제가 무엇인가요 ? 해당 테이블에 update 를 하면 자꾸 lock 에 걸려서 update 가 안되는 현상.

※ dba 가 위와 같은 상황을 해결하는 팁 !
1. in-doubt 트랜잭션의 sid 와 serial# 을 알아낸다.
2. 강제로 in-doubt 트랜잭션을 kill

alter system kill session '29,28844' immediate;
sid, serial#

■ 실습

자동 커밋 되는 것을 막고 시작해야한다 !

#1. 짝의 테이블들 select 할 수 있도록 db 링크를 생성

create database link jyp_link
connect to scott
identified by tiger
using '192.168.19.45:1521/orcl.us.oracle.com';

select * from emp@jyp_link;

#2. 짝의 emp 테이블을 update 한다

SQL> update emp@jyp_link
2 set sal=0
3 where ename='KING';

내가 -> 45 번의 데이터를 변경 하고 위의 UPDATE 문을 실행하는 터미널이 비정상적으로 꺼졌다고 가정한다.

#3. 45번 자리에서 새로운 터미널을 열고 다음과 같이 UPDATE 를 한다.

SQL> update emp
2 set sal =7000
3 where ename = 'KING';

문제1. 위의 상황을 해결하시오

sqldeveloper - 리눅스의 오라클

sqldeveloper 의 세션 모니터 또는
dbever 의 세션 메니저를 열어서 update 하면 inactive 인 세션을 찾아서 kill 시키면 됩니다.

update emp@jyp_link
set sal=0
where ename='KING';

위의 상황을 만들어 놓고 다른 터미널 창을 열어서 sys 유져로 접속해서
락 홀더와 락 waiter 를 조회합니다.

▩ 20. ARCn (Archive process)

리두로그파일을 백업하는 프로세서 입니다.

리두 로그 파일이 덮어지기 전에 백업하는게 아카이브 프로세서

• 오라클은 내부적으로 임의의 변경사항이 발생하게 되면 이러한 하나한의 변경 정보들을 '리두 로그'라는 형식으로 메모리 상에서 발생시키고 리두 로그 버퍼라는 메모리 영역에 일단 저장시킨다. 리두 로그 버퍼는 주로 DDL 또는 DML 문장에 의하여 데이터베이스에 저장된 값 또는 데이터베이스 구조에 변경이 생기는 경우 이러한 변경 정보를 놓치지 않고 저장하는 메모리 영역이다. 리두 로그 버퍼에 저장되는 이러한 정보들은 커밋이 되는 순간 로그라이터(LGWR)라는 백그라운드 프로세스에 의하여 리두 로그 파일로 물리적으로 저장된다. 이처럼 물리적으로 리두 로그 파일로 내려 적는 이유는 간단하다. 중요한 정보인데 리두 로그 버퍼라는 메모리에만 저장한다는 것은 다소 위험하기 때문이다.

아카이브프로세서

■ 실습
#1. 데이터베이스 모드가 아카이브 모드인지 노 아카이브 모드인지 확인하시오 !

아카이브 모드 : 아카이브로그 파일을 생성시키는 모드
sys 로 접속

#2. 아카이브 모드로 변경하기 위해서 db를 정상종료 합니다.

#3. startup 단계를 mount 단계로 올립니다.

SQL> startup mount

SQL> select status from v$instance;

STATUS
..................
MOUNTED

#4. 데이터베이스 모드를 archive 모드로 변경합니다.

SQL> alter database archivelog;

Database altered.

SQL> alter database open; ------------------------ 오픈으로 올림

Database altered.

실습2. 리두 로그 파일 관련 실습

#1. 리두 로그 파일의 그룹의 개수를 확인하시오 !

SQL> select group#, status, sequence#
from v$log;

SQL> alter system switch logfile;

System altered.

#3. 로그 스위치를 일으키고 현재 쓰고있는 리두로그 그룹이 다음 그룹으로 넘어갔는지 확인

실습3. 아카이브 리두 로그 파일이 생성되었는지 확인하는 방법

#1. 먼저 아카이브 리두 로그 파일의 위치가 어디인지 확인하시오 !

SQL> archive log list

#2. 아카이브 로그 파일의 위치를 알고 있는 파라미터를 조회합니다.

asm 디스크 Automatic Storage Management
db_recovery_file_dest string +FRA 이건 리눅스에서 안보이고 asm 으로 가야함

#3. +FRA 라는 ASM 디스크 그룹 위치로 이동합니다.
DB 인스턴스 ASM 인스턴스

[orcl:~]$ . oraenv

ORACLE_SID = [orcl] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid is /u01/app/oracle

[+ASM:~]$ asmcmd ------ >asm커맨드로 접속

ASMCMD> ls
DATA/
FRA/

ASMCMD>

오늘날짜 폴더까지 확인.

문제1. 다시 노아카이브 모드로 변환하시오 !

답:
#1. db 정상종료 합니다.
#2. db를 마운트로 올린다.
#3. 노아카이브 모드로 변환한다.
#4. db를 open 까지 올린다
#5. 아카이브 모드를 확인합니다.

SQL> shutdown immediate
Database closed.
Database dismounted.
sORACLE instance shut down.
SQL>startup mount
ORACLE instance started.

Total System Global Area 481259520 bytes
Fixed Size 1337352 bytes
Variable Size 335546360 bytes
Database Buffers 138412032 bytes
Redo Buffers 5963776 bytes
Database mounted.
SQL> alter database noarchivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 31
Current log sequence 33

21. 프로세서 시작 시퀀스 (Oracle Database 11g: Administration Workshop I 1 - 32)

grid infrastructrue의 역할 : ASM 을 관리한다.
ASM : 자동으로 스토리지 관리하는 프로그램.

22. 데이터 베이스 저장영역 구조

#예제1. 데이터베이스를 수동으로 설치 하시오 !

데이터베이스를 구성하는 파일 8가지

1. data file : data 를 저장함
2. redo log file : 변경사항을 기록하는 파일
3. control file : db의 구조정보를 담고 있는 파일
   ---------------------- 이 위의 3개는 무조건 지켜야 함 아니면 멸망함
4. archive log file : 리두로그파일의 백업본
5. parameter file : 인스턴스의 구성 정보가 들어있는 파일
6. password file : 특별한 권한을 가진 유져를 인증해주기 위한 파일
7. alert log file trace file : 오라클을 진단하기 위해서 필요한 파일
8. 백업파일 : 백업본

실습
#1. data file 의 위치를 확인하시오
윈도우21c sqlplus sys/oracle_4U as sysdba
SQL> select file_name from dba_data_files;

[+ASM:~]$ asmcmd
ASMCMD> pwd

• ASMCMD> cd orcl
  ASMCMD-08001: diskgroup 'orcl' does not exist or is not mounted
  ASMCMD> ls
  DATA/
  FRA/
  ASMCMD> cd data
  ASMCMD> ls
  ASM/
  ORCL/
  ASMCMD> cd orcl
  ASMCMD> ls
  CONTROLFILE/
  DATAFILE/
  ONLINELOG/
  PARAMETERFILE/
  TEMPFILE/
  spfileorcl.ora
  ASMCMD> cd datafile
  ASMCMD> ls
  EXAMPLE.265.796857803
  SYSAUX.257.796857623
  SYSTEM.256.796857621
  UNDOTBS1.258.796857625
  USERS.259.796857625

#2. control file 의 위치를 확인하시오 !

윈도우 : select name from v$controlfile; SQL> select name from v$controlfile;

#3. redo log file 의 위치를 확인하시오
윈도우(21c): select member from v$logfile;

리눅스(11g): select member from v$logfile;

윈도우와 리눅스 개수가 다른 이유

#4. 아카이브 로그 파일의 위치를 확인하시오 ~

윈도우 : SQL> archive log list
리눅스 : select dest_name from v$archive_dest;

#5. 파라미터 파일의 위치를 확인하시오

윈도우 : SQL> show parameter spfile
리눅스 : SQL> show parameter spfile

#6. 패스워드 파일의 위치를 확인하시오 !

 sys유져의 패스워드가 등록되어있는 파일입니다.

윈도우 : SQL> show parameter spfile

패스워드파일이 spfile 이 있는 곳에 같이 있습니다. PWDorcl.ora

리눅스 : $ cd $ORACLE_HOE/dbs$ ls -l orapworcl
-rw-r----- 1 oracle oinstall 1536 1월 16 15:16 orapworcl

#7. alert log file 과 trace file 의 위치를 확인하시오 !

오라클에 문제가 생겼을 때 진단을 위해서 봐야하는 파일
윈도우 : SQL> show parameter background_dump_dest
리눅스 SQL> show parameter background_dump_dest

■ 실습

#1. alert log file 이 있는 곳으로 이동 하시오.

$cd /u01/app/oracle/diag/rdbms/orcl/orcl/trace

#2. alert log file 이 있는지 확인 하시오 (ls)

$ ls -l alert*
-rw-r----- 1 oracle dba 171769 1월 31 14:57 alert_orcl.log

#3. alert log file 뒷부분만 열어서 실시간으로 변경되면 계속 변경되는걸 보이게 하시오.

$ tail -f alert* : dba 들은 수시로 봐야 함. (쉘스크립트) 수시로 - 문제생길때 , db를 올렸다 내렸을 때 등

#4. 다른 터미널창을 열어서 db 를 내렸다 올리시오 !

문제1. alert log file 이 있는 위치로 이동해서 tail -f alert* 명령어를 수행해서
alert log file 을 쉽게 모니터링 할 수 있게 dba.sh 에 추가하시오

vi dba.sh

문제2. asmcmd 모드로 접속하는 쉘도 추가하시오

vi dba.sh

오늘의 마지막 문제. dba.sh 에 datafile 의 위치를 확인하는것을 추가하시오

[2] datafile 의 위치와 파일을 확인하려면 2번을 누르세요

2번을 누르면 결과가 다음과 같이 출력되면 됩니다.
sysdba 에서
SQL> select file_name from dba_data_files;

@datafile.sql