mellowg

리스너 로그 확인

리스너 로그를 통해서 언제 어떤 클라이언트가 접속을 시도했는지 확인할 수 있다. 그러나 client의 접속 요청이 Listener에게 도달하기 전에 문제가 발생한 경우에는 리스너 로그에 아무것도 남지 않는다. 

만약 client 접속 요청이 실패하는 경우 리스너로그 확인 후 리스너 로그에 아무런 로그가 남아있지 않다면 네트워크 쪽을 확인해보거나 해야 하며, 로그가 남은 경우에 로그 기록에 따라 조치를 취하면 된다.

리스너 로그 조회

$ cat $TB_HOME/instance/$TB_SID/log/lsnr
$ vi trace_list.log 
# or $ tail -n10 trace_list.log

로그 예시

# 세션에 클라이언트 접속요청 후 접속 성공한 경우 발생하는 로그
2025/07/30 16:08:43.990291 [5] listener:1452 a new client connection detected.
2025/07/30 16:08:43.990326 [5] listener:1371 a client connection from [127.0.0.1:44318] # 접속 요청한 클라이언트 정보
2025/07/30 16:08:43.990332 [5] listener:1494 a client from IP socket
2025/07/30 16:08:43.990344 [5] listener:3104 sent a connection fd to the WTHR process 1 successfully. # 클라이언트 WTHR(WORKER THREAD) 커넥션 성공

리스너 로그가 현재 어떤 포트를 리스닝하는지 확인

$  netstat -tlpn | grep tblistener
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8629            0.0.0.0:*               LISTEN      2026/tblistener

DB 접속 세션 끊기

DBA가 DB관련 작업을 할 때 모든 세션을 끊고 작업을 해야하는 경우가 있다. 실제 운영중인 서버인 경우 세션이 붙어있을 것이다. 이때는 세션이 연결되지 못하도록 막고, 기존 세션들을 끊는 작업이 필요하다. 

반드시 세션이 연결되지 못하도록 막는 것이 선행되어야 한다. (은행 창구에 대입하여 생각하면 이해하기 쉽다.)

은행 번호표 뽑는 것을 막지 않고 기존 고객을 쫒아내더라도 번호표는 계속 뽑히고 있을테니 계속해서 손님은 들어올 것이다. 번호표 기계를 먼저 종료한 후 기존 고객 거래를 끝내야 은행창구에 아무도 없을 것이다.

세션이 연결되지 못하도록 하려면 어떻게 해야할까?

세션을 연결하도록 하는 것은 Listener의 역할이다. Listener가 더이상 세션 연결 요청을 리스닝하지 못하도록 OFF 하는 방법이 있다.

1. 신규 세션 생성 막기

리스닝 OFF

리스닝 off 의 경우 아래 명령어를 실행하면 된다. 반대로 리스닝 ON은 OFF를 ON으로 변경하여 실행하면 된다.

ALTER SYSTEM LISTENER REMOTE OFF;

작업 후 netstat -tlpn | grep tblistener 조회해보면 아무것도 출력되지 않은 것을 확인할 수 있다.

2. 기존 세션 연결 끊기

기존 세션 연결 끊는 명령어는 아래와 같다. SID 와 SERIAL# 값은 V$SESSION 시스템뷰나 tm(tibero monotor)를 통해서 조회할 수 있다. 여기서는 V$SESSION을 통해 조회해보자

ALTER SYSTEM KILL SESSION(SID, SERIAL#);

V$SESSION을 통해 SID, SERIAL# 값 조회하기

VT_MYTID를 통해 나는 어떤 SID를 사용중인지 확인이 꼭 필요하다. 실수로 나의 연결을 끊어버릴 수 있기 때문이다.

SELECT 
	SID, 
	SERIAL#,
	USERNAME,
	PROG_NAME
FROM V$SESSION;

# 조회 결과
#	SID	SERIAL#	USERNAME	PROG_NAME
1	77	6,058	SYS	tbsql
2	87	632	TIBERO	Studio
3	88	1,360	SYS	tbsql
4	89	1,051	SYS	Studio

# 나는 어떤 SID 사용중인지?
SQL > SELECT * FROM VT_MYTID; -- 77

# 기존 접속 끊기
ALTER SYSTEM KILL SESSION(87, 632);
ALTER SYSTEM KILL SESSION(88, 1360);
ALTER SYSTEM KILL SESSION(89, 1051);

Cookie?

HTTP Cookie(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각을 의미한다.

서버가 브라우저에게 쿠키를 전달하면 브라우저는 쿠키를 저장해두었다가(브라우저 저장소에), 쿠키를 전달해준 동일한 서버에 클라이언트가 재 요청을 하게 되면 저장된 쿠키를 서버에 함께 전송한다.

Cookie는 서버가 요청이 동일한 브라우저에서 왔는지 확인할 때 주로 사용한다. 예시로 쿠키를 통해 사용자의 로그인 상태를 유지할 수 있다.

Cookie의 사용 목적

• 세션 관리 (Session Management)
  • 서버에 저장해야 할 로그인, 게임 스코어 등의 정보 관리
• 개인화 (Personalization)
  • 사용자 선호, 테마 등의 세팅
• 트래킹 (Tracking)
  • 사용자 행동을 기록하고 분석하는 용도

Session?

Session은 쿠키를 기반으로 한다. 그러나 Cookie와 가장 큰 차이점은 사용자의 정보를 브라우저에 저장하는 쿠키와 달리 세션은 서버에서 관리한다.

사용자에 대한 정보를 서버에서 저장하여 관리하기 때문에 보안상 쿠키보다 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.

Client가 Server에 Request를 보내면, Server가 Client에게 Unique한 Id를 부여한다. 이것이 SessionId이다.

Cookie VS Session