'분류 전체보기' 카테고리의 글 목록 (36 Page)

--- Arup Nanda 의 사이트에 자주 들어가봅니다. DBA 로서의 장애 Case 를 대응하는 절차가 비교적 자세히 나와있더군요. 요즘 일이 많아서 빠르게 쓰다보니 오역과 중간중간 빼먹는게 많은건 이해해주시길...아래는 실제로 DMA (direct memory access)를 사용해서 처리한 사례더군요..

Diagnosing Library Cache Latch Contention: A Real Case Study

어느날 DW 서버가 갑자기 다운됐다. 그래서 데이타베이스를 올리고 다시 구동했지만 모든 접속을 시도하면
hang 이 걸리는 것이였다. 따라서 접속은 실패하고 DBA는 접속된 세션들이 구동되고 있는지 어떤지를 확인할 수 조차도
없었다. DBA 는 WAIT 이벤트를 체크했다 (그러나 로긴조차도 안되기 때문에 실행할수 없었다)
흥미롭게도 CPU는 70% 정도의 수준이였고 이는 낮시간대의 일반적인 수치이다. 그리고 I/O또한 약 90%로서 이또한
일반적인 수치였다.

따라서 전형적인 방법인 system 관리자에게 보고하고 재부팅을 하는 방법을 사용했다. 재부팅은 30분정도
소요되었고 그 후로 10여분간은 모든것이 정상적으로 보였다. 그러나 얼마되지 않아 아까와같은 똑같은 문제에 부딪쳤다- 데이타베이스가 먹통이 되어버린 것이였다.

이것 때문에 DBA가 나에게 도움을 요청하였다. 이 블로그에서는 내가 이후의 30분동안에 어떻게 수행했고 문제를
해결했는지에 대해서 기술해보도록 하겠다.

증상

(1) 데이타베이스 접속 Hanging
(2) SQL*PLUS AS SYSDBA 로 접속해도 동일한 HANGING 현상: 증상을 확인할 수도 없는 상태
(3) 시스템은 아무때나 리부팅할 수 없는 상태

Action

여기서 접속이 불가능할 때 데이타베이스 인스턴스에서 바로 써먹을 수 있는 꼼수가 존재한다.
대부분의 사람들은 SQL*Plus 에서 "prelim" 이라고 불리는 옵션을 잘알지 못한다. 이 옵션은 세션을 열지 않고
SGA에 바로 접속한수 있는 옵션이다. (10g 이상에서만 가능)

(1) 먼저 SQL*plus 를 실행시키고 아래의 명령문을 실행했다.

$ sqlplus -prelim / AS SYSDBA
SQL>

명심하라. "Oracle Database 10.2.0.3 에 접속" 과 다르다. 지금 보이는 SQL> 프롬프트는 실제로는
데이타베이스에 접속한 상태가 아니다.

(2) 그다음 SGA 를 분석하기 위한 "oradebug" 를 사용하였다.

SQL> oradebug setmypid
SQL> oradebug hanganalyze 12

이 명령은 USER_DUMP_DEST 에 trace파일을 생성한다. 이 파일을 가장 최근에 생겨났기 때문에
쉽게 찾을 수 있다. 심지어는 내가 파일을 찾지 못해도 process ID를 사용해서 파일을 찾을 수 있다.
내가 찾은 파일은 프로세스ID 가 13392인 crmprd1_ora_13392.trc 였다.

(3) 파일을 조사하니 다음과 같았다.

*** 2008-08-23 01:21:44.200
==============
HANG ANALYSIS:
==============
Found 163 objects waiting for
<0/226/17/0x1502dab8/16108/no>
Open chains found:
Chain 1 : :
<0/226/17/0x1502dab8/16108/no>
<0/146/1/0x1503e898/19923/latch:>

이 파일을 많은 것을 말해준다. SID 146 에 Serial# 1 이 library cache latch 를 대기하고 있는 것을 보여준다.(맨마지막줄)
그리고 blocking 세션은 SID 226 Serial# 17 로 나와있다.

나는 일단 이 OS process ID 인 16108 과 19923 을 기록해두었다.

(4) 다음으로 위의 두개의 OS PID 명으로 되어 있는 TRACE 파일을 체크했다.

crmprd1_ora_16108.trc
crmprd1_ora_19923.trc

(5) 먼저 BLOCKER인 첫번째 파일을 열었다. 다음 몇줄의 예이다.

*** 2008-08-23 01:08:18.840
*** SERVICE NAME:(SYS$USERS) 2008-08-23 01:08:18.781
*** SESSION ID:(226.17) 2008-08-23 01:08:18.781
LIBRARY OBJECT HANDLE: handle=c0000008dc703810 mtx=c0000008dc703940(8000) cdp=32737
name=UPDATE DW_ETL.FRRS_PROFILER SET CONSUMER_LINK = :"SYS_B_0", ADDRESS_LINK = :"SYS_B_1", ADDRESS_MATCH = :"SYS_B_2", PROC
ESSED=:"SYS_B_3" WHERE RNUM = :"SYS_B_4"
hash=a029fce7bb89655493e7e51a544592a4 timestamp=08-23-2008 00:10:23
namespace=CRSR flags=RON/KGHP/TIM/OBS/PN0/MED/KST/DBN/MTX/[504100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=10 hpc=0058 hlc=0058
lwt=c0000008dc7038b8[c0000008dc7038b8,c0000008dc7038b8] ltm=c0000008dc7038c8[c0000008dc7038c8,c0000008dc7038c8]
pwt=c0000008dc703880[c0000008dc703880,c0000008dc703880] ptm=c0000008dc703890[c0000008dc703890,c0000008dc703890]
ref=c0000008dc7038e8[c0000008dc7038e8,c0000008dc7038e8] lnd=c0000008dc703900[c0000008dc703900,c0000008dc703900]
LOCK OWNERS:
lock user session count mode flags
---------------- ---------------- ---------------- ----- ---- ------------------------
c0000008d079f1b8 c0000006151744d8 c0000006151744d8 16 N [00]
c0000008d4e90c40 c0000006151bcb58 c0000006151bcb58 16 N [00]
c0000008d0812c40 c0000008151a0438 c0000008151a0438 16 N [00]

(6) 이것은 디버깅을 위해 보물과 같았다. 첫번째에 SID와 Serial#(226,17) 를 확인할수 있다.
이를 사용해서 정확한 SQL문장을 볼수 있다. 또한 락에 대한 전체적인 상황을 볼 수 있다. 락의 자세한 사항은 신경쓰지 않아도 되지만 SID 226 이 전체 세션의 대기를 유발시키는 것이라는 충분한 정보를 제공해주었다.

(7) 나의 조사는 여기서 그치지 않고 이 대기를 유발하는 세션을 찾기를 시도했다. 따라서 나는 파일의 "PROCESS STATE" 이라는 섹션을 조사했다. 다음은 이 파일의 일부분이다.

PROCESS STATE
-------------
Process global information:
process: c00000081502dab8, call: c000000817167890, xact: 0000000000000000, curses: c00000081519ef88, usrses: c000000815
19ef88
----------------------------------------
SO: c00000081502dab8, type: 2, owner: 0000000000000000, flag: INIT/-/-/0x00
(process) Oracle pid=370, calls cur/top: c000000817167890/c000000817167890, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 115 0 4
last post received-location: kslpsr
last process to post me: c000000615002038 1 6
last post sent: 0 0 24
last post sent-location: ksasnd
last process posted by me: c000000615002038 1 6
(latch info) wait_event=0 bits=20
holding (efd=4) c0000008d7b69598 Child library cache level=5 child#=10
Location from where latch is held: kglhdgc: child:: latch
Context saved from call: 13
state=busy, wlstate=free
waiters [orapid (seconds since: put on list, posted, alive check)]:
291 (197, 1219468295, 197)
279 (197, 1219468295, 197)
374 (197, 1219468295, 197)
267 (197, 1219468295, 197)
372 (197, 1219468295, 197)
... several lines sniped ...
307 (15, 1219468295, 15)
181 (6, 1219468295, 6)
waiter count=58
Process Group: DEFAULT, pseudo proc: c0000008e03150d8
O/S info: user: oracrmp, term: UNKNOWN, ospid: 16108
OSD pid info: Unix process pid: 16108, image: oracle@sdwhpdb1

(8) 이파일은 내가 알기를 원하는 것을 모두 말해준다. 여기에 SID 226 에 의해서 발생하는 CACHE LATCH
로 인해서 대기하는 58 session들이 있다. 여기서 OS PROCESS ID 와 BLOCKING 세션의 SQL 문장을 알 수 있다.

(9) 나는 application 사용자가 어떠한 것을 실행했는지를 조사해봤더니 사용자는 loop를 돌면서 처리하는
update 문장을 실행시킨 것이였다. 그리고 그게 다가 아니라 다른 8개의 thread 에서 실행을 하였다.(역: 아마도 화면상에서 처리 가 되지 않으니 화면을 새로고쳐서 계속해서 8번을 처리 버튼을 누른것으로 생각됨)
의심할 여지가 없이 library cache latch 경합에 걸렸다. 모든 세션은 각각의 덤프 정보를 남겼다.
그리고 나는 같은 문장을 실행한 파일을 디렉토리에서 조사해보기로 했다.

$ grep “UPDATE DW_ETL” *.trc

(10) 나는 9개 이상의 세션(프로세스) 파일을 찾았다. 이중 한개의 파일의 일부분이다.

350 (167, 1219470122, 167)
197 (167, 1219470122, 167)
waiter count=185
Process Group: DEFAULT, pseudo proc: c0000008e03150d8
O/S info: user: oracrmp, term: UNKNOWN, ospid: 16114

이 프로세스 한개가 185개 waiter 를 가졌다!!!

$ kill -9

(12) 위의 명령으로 몇개의 프로세스를 죽인 후에야 데이타베이스는 응답하기 시작했다. 모든 프로세스를 죽인 후에는 데이타베이스 wait event 가 완벽히 정상적으로 돌아왔다.

참고사항

(1) Hang 이라고 생각되면 너무 그것에 대해 불안해하지 마라. 세션은 언제나 어떤것을 대기한다. 드물게 행을 만날 뿐이다.

v$session (10g) 이나 v$session_wait 의 EVENT 컬럼을 조회해서 대기하는 것이 무엇인지를 먼저 체크하라.

(2) 데이타베이스에 로긴하지 못해 정보를 얻을 수 없을 때는 oradebug 명령을 사용한다.

(3) oradebug 를 사용할때 SQL*Plus 를 이용한다. 로긴하지 못할때 "sqlplus -prelim " 로 SQL prompt 를 얻을 수 있을 것이다.

(4) oradebug setmypid 이용해서 oradebug 세션을 시작하고 oradebug hanganalyze 로 모든 hang 과 관련되어 있는

문제에 대한 덤프를 생성한다.

(5) oradebug help 를 사용해서 oradebug 커맨드의 모든것을 볼 수 있다.

[출처] DB에 Connect 할수 없을 때의 진단 - Case Study(Library Cache Latch Contention)|작성자 꾸니

저작자표시 (새창열림)

'Database > ORACLE' 카테고리의 다른 글

오라클 일괄 컴파일 (0)	2010.06.30
프로시저에서 엑셀파일 출력하기 (0)	2010.06.29
Oradebug 사용법 (0)	2010.03.26
ErrorStack 덤프를 이용해 문제 SQL 찾아내기 (0)	2010.03.26
간단한 방법으로 SID 변경하기 (nid 사용) (0)	2010.03.15

Oradebug 사용법
- 적절한 권한을 가진 DB USER 로 sqlplus 로 접속
- 반드시 덤프할 오라클 프로세스를 지정한 후 사용
- SYNTAX : SQL>oradebug command <option>

일반 유저도 Try

SQL> show user
USER is "SCOTT"
SQL> oradebug setmypid
ORA-01031: insufficient privileges

SQL> conn / as sysdba
Connected.
SQL> show user
USER is "SYS"
SQL> oradebug setmypid
Statement processed.

==> 자신의 process ID 지정 해서 dump

일반 유저를 찾아서 지정 해보기

보통은[AIX 환경] ps aux | sort -k3 으로 cpu 과도 사용 Unix process ID 를 찾은 후

지정 해서 dump 를 떨군 후 분석을 하면 될듯

## Scott User 의 Process ID 찾기
SQL> select username, sid, serial#,PADDR from v$session where username ='SCOTT';

USERNAME SID SERIAL# PADDR
------------------------------ ---------- ---------- --------
SCOTT 28 54 46CB5768

SQL> select * from v$process where addr = '46CB5768';

ADDR            PID SPID      USERNAME           SERIAL#
-------- ---------- --------- --------------- ----------
TERMINAL                       PROGRAM
------------------------------ ------------------------------------------------
TRACEID
--------------------------------------------------------------------------------
B LATCHWAI LATCHSPI
- -------- --------
46CB5768         29 283314    oracle                   2
pts/8                          oracle@seldw (TNS V1-V3)

## Unix 환경에서 파악

[CRAFT]seldw:/app/oracle/tg> ps -ef| grep 283314
oracle 282448 290026 0 10:45:26 pts/7 0:00 grep 283314
oracle 283314 284036 0 10:42:54 - 0:00 oracleCRAFT (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

SQL> oradebug unlimit
Statement processed.
==> Dump 화일 무제한으로 설정
SQL> oradebug setospid 283314
Oracle pid: 29, Unix process pid: 283314, image: oracle@seldw (TNS V1-V3)

==> Scott Process ID 를 지정 해서 dump
SQL> oradebug tracefile_name
Statement processed.
==> dump 화일명 체크

==> 나오지 않는다.

SQL> oradebug dump errorstack 3
Statement processed.
==> dump 화일에 실제 Write 되도록 command 를 날리기

SQL> oradebug tracefile_name
/app/oracle/admin/CRAFT/udump/ora_283314_craft.trc
==> 이제 화일명이 보임

# Event 로 Trace 걸기
SQL> oradebug setospid 283314
Oracle pid: 29, Unix process pid: 283314, image: oracle@seldw (TNS V1-V3)

# 10046 Event 에 대해서 Trace 생성도록 설정 하기
SQL> oradebug event 10046 trace name context forever, level 12
Statement processed.
SQL> oradebug event 10046 trace name context off
Statement processed.
SQL> oradebug tracefile_name
/app/oracle/admin/CRAFT/udump/ora_283314_craft.trc

CASE 1 : 특정 프로세스가 SPIN 또는 HANG
SQL> oradebug dump errorstack 3 .. 3분단위 3번수행
SQL> oradebug dump processstate 10 .. 비교1
SQL> oradebug event 942 errorstack 10 .. 비교2

CASE 1 은 특정 프로세스가 SPIN 또는 HANG 으로 보이는 경우입니다.
(1) Oradebug setospid 해당 프로세스를 덤프대상으로 지정하고
(2) Oradebug dump errorstack 3 으로 ERRORSTACK 을 2-3번 떠서
(3) CALL STACK 부분이 변하고 있는지 비교해봅니다.
변하고 있으면 SPIN 이고, 변하지 않고 있으면 HANG 이라고 결론 내릴 수 있습니다.
ERRORSTACK LEVEL 3 에 PROCESSSTATE DUMP 가 포함되므로
PROCESSSTATE DUMP 를 별도로 수행할 필요가 없습니다.
EVENT Command 에서 ERRORSTACK 를 설정할 때와 비교해보면, EVENT Command 는 해당 에러가 발생하는
시점에 에러스택이 생성되는 것이고, DUMP Command 는 Oradebug Command 를 수행하자마자 에러스택이
생성됩니다.

CASE 2 : 데이터베이스 SPIN 또는 HANG
SQL> oradebug dump systemstate 10 .. 3분간격 3번수행
= alter session set events 'immediate trace name SYSTEMSTATE level 10';

케이스 두번째, 드디어 SYSTEMSTATE DUMP 입니다.
이 Command 는 아마도 oradebug 에서 가장 많이 사용되는 명령어로
alter session set events 'immediate trace name SYSTEMSTATE level 10'; 과 같습니다.
보시다시피 Oradebug Command 가 훨씬 간단하고 Rule 만 알면 외울 필요도 없습니다.
인스턴스 HANG 시 3분 간격으로 3번을 수행한 결과가 있어야 Slow Performance 인지,

진짜 HANG 이였는지 판단할 수 있습니다.

SQL> oradebug dump systemstate 10
ORA-00074: no process has been specified
SQL> alter session set events 'immediate trace name systemstate level 10';

Session altered.

CASE 3 : 프로세스 메모리가 비정상 증가하는 경우
SQL> oradebug dump heapdump 5 .. PGA+UGA

CASE 4 : SGA 부족으로 ORA-4031 가 발생하는 경우
SQL> oradebug dump heapdump 2 .. SGA
event="4031 trace name HEAPDUMP level 2" in initSID.ora

CASE 6 : 리커버리시 데이터파일 상태 불일치 에러시
SQL> oradebug dump controlf 10
SQL> oradebug dump file_hdrs 10
==>테스트시 임의의 프로세스 지정을 해야 trace 화일이 생성 된다.

SQL> oradebug dump controlf 10
ORA-00074: no process has been specified
SQL> oradebug setospid 283314
Oracle pid: 29, Unix process pid: 283314, image: oracle@seldw (TNS V1-V3)
SQL> oradebug dump controlf 10
Statement processed.
SQL> oradebug tracefile_name
/app/oracle/admin/CRAFT/udump/ora_283314_craft.trc
SQL> oradebug dump file_hdrs 10
Statement processed.
SQL> exit

SQL> oradebug hanganalyze 3
Hang Analysis in /app/oracle/admin/CRAFT/udump/ora_89222_craft.trc
프로세스 또는 인스턴스 HANG 진단 및 분석시 유용
HANGANALYZE [level]
1-2 Only HANGANALYZE output, no process dump
3 Level 2 + HANG 으로 추정되는 프로세스 덤프
4 Level 3 + WAIT CHAIN 의 BLOCKER 프로세스
5 Level 4 + WAIT CHAIN 의 모든 프로세스
10 모든 프로세스 덤프

SQL> oradebug hanganalyze 3 .. 권장레벨, 또는 1
Hang Analysis in /home/ora920/ora920_1190.trc
HANGANALYZE TRACEFILE SECTIONS 설명
CYCLES : Deadlock 관계 세션들의 CHAIN
BLOCKER OF MANY SESSIONS : 10개 이상의 세션을 blocking 하는 BLOCKER 제시
OPEN CHAINS : 1개 이상의 타 세션들을 blocking 하는 세션이 포함된 WAIT CHAIN
OTHER CHAINS : OPEN CHAIN 의 세션들과 간접적으로 관련있는 프로세스 리스트

EXTRA INFORMATION : 덤프 레벨에 따른 프로세스 Errorstack 등의 추가 정보
STATE OF NODES : 모든 세션들 DEPENDENCY GRAPH
IN_HANG - HANG
IGN - IGNORE
LEAF - A waiting leaf node
LEAF_NW - A running leaf node
NLEAF - STUCK
세션 STATE 설명입니다.
IN_HANG : 심각한 상태로, 이 상태의 세션은 DEADLOCK 가능성이 있습니다 .
IGN and IGN_DMP : IDLE 상태이므로 무시하셔도 됩니다.
LEAF and LEAF_NW : 이 상태로 Wait Chain 의 가장 앞에 있으면,

바로 이 세션이 Blocker 세션입니다.
NLEAF : STUCK 세션으로, 다른 세션이 리소스를 잡고 안 놓아 주는 상태

로 Performance 이슈일가능성이 높습니다.

DB HANG 이것만은 알아두세요!!!
데이터베이스 HANG : DB 연결될 때
SQL> oradebug setmypid

자신의 Process ID 지정 아마도, trace file 생성을 위해서 임의로 지정하는 듯
SQL> oradebug unlimit

Trace file 무한으로 설정
SQL> oradebug hanganalyze 1

빨리 Blocker 찾으세요

Trace 화일을 통해서 문제의 Process ID 를 서치

심도 있게 더 깊이 분석시 아마도 setospid를 통해서 Blocker ID 를 찾은수

다시 trace 를 시도 하면 될듯
SQL> oradebug dump systemstate 10 ..

다른세션에서 3분3번

데이터베이스 HANG : DB 연결안 될 때
$ dbx .a PID $ORACLE_HOME/bin/oracle .. Oracle PID
dbx) call ksudss(10) or print ksudss(10)
dbx) detach

RAC에서 다른 Instance와의 연관된 내용까지 분석하려면 다음과 같은 명령문을 사용해야 한다.

SQL> oradebug setinst all
SQL> oradebug --g def hanganalyze 1

SQL> oradebug hanganalyze <level> -- 예: oradebug hanganalyze 3
Level에 따른 출력 내용은 다음과 같다.

    * 10 - Dump all processes (IGN state)
    * 5 - Level 4 + Dump all processes involved in wait chains (NLEAF state)
    * 4 - Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state)
    * 3 - Level 2 + Dump only processes thought to be in a hang (IN_HANG state)
    * 1-2 - Only HANGANALYZE output, no process dump at all

[출처] Oradebug Command|작성자 타락천사

저작자표시 (새창열림)

'Database > ORACLE' 카테고리의 다른 글

프로시저에서 엑셀파일 출력하기 (0)	2010.06.29
DB에 Connect 할수 없을 때의 진단 - Case Study(Library Cache Latch Contention) (0)	2010.03.26
ErrorStack 덤프를 이용해 문제 SQL 찾아내기 (0)	2010.03.26
간단한 방법으로 SID 변경하기 (nid 사용) (0)	2010.03.15
Oracle SID error (0)	2010.02.09

오라플에서 에러가 발생했을 때, 어떤 SQL문이 문제인가를 찾아낼 필요가 있습니다. 예를 들어, Alert.log 파일에 다음과 같은 에러 메시지가 기록되어 있습니다.

`1`	`Fri Mar 05 09:47:53 2010`

`2`	`ORA-1652: unable` `to` `extend` `temp` `segment` `by` `128` `in` `tablespace VERY_SMALL_TBS`

어떤 SQL문이 범인인가를 알지 못하면, 해결하기가 쉽지 않습니다.

이런 경우에 시도해 볼 수 있는 것이 ErrorStack 덤프입니다. ErrorStack 덤프를 진단 이벤트와 함께 사용하면 에러를 일으키는 SQL 문장이 트레이스 파일에 기록되도록 할 수 있습니다.

간단한 예를 설명해 보겠습니다. 우선 작은 크기(10m)의 테이블스페이를 만듭니다.

1
UKJA@ukja1021> create tablespace very_small_tbs 

2
  2  datafile size 10m; 

3
  
4
Tablespace created.

ORA-01652 에러가 발생하면, ErrorStack 덤프를 실행하도록 진단 이벤트를 겁니다.

1
UKJA@ukja1021> alter system set events '1652 trace name errorstack level 1, forever'; 

2
  
3
Session altered.

10m보다 큰 테이블을 만들면 ORA-01652 에러가 발생합니다.

01
UKJA@ukja1021> create table tbig(c1) 

02
  2  tablespace very_small_tbs 

03
  3  as

04
  4  select rpad('x',1000) from dual 

05
  5  connect by level <= 10000 

06
  6  ; 

07
select rpad('x',1000) from dual 

08
                           * 

09
ERROR at line 4: 

10
ORA-01652: unable to extend temp segment by 128 in tablespace VERY_SMALL_TBS 

11
  
12
UKJA@ukja1021> alter system set events '1652 trace name context off'; 

13
  
14
Session altered.

Alert.log 파일에는 다음과 에러 메시지가 남습니다.

`1`	`Fri Mar 05 09:47:53 2010`

`2`	`ORA-1652: unable` `to` `extend` `temp` `segment` `by` `128` `in` `tablespace VERY_SMALL_TBS`

프로세스의 트레이스 파일에는 에러 발생시의 SQL문과 CallStack 트레이스가 기록되어 있습니다.

01
ORA-01652: unable to extend temp segment by 128 in tablespace VERY_SMALL_TBS 

02
Current SQL statement for this session: 

03
create table tbig(c1) 

04
tablespace very_small_tbs 

05
as

06
select rpad('x',1000) from dual 

07
connect by level <= 10000 

08
----- Call Stack Trace ----- 

09
calling              call     entry                argument values in hex       

10
location             type     point                (? means dubious value)      

11
-------------------- -------- -------------------- ---------------------------- 

12
_ksedst+38           CALLrel  _ksedst1+0           0 1 

13
_ksedmp+898          CALLrel  _ksedst+0            0 

14
_ksddoa+2088         CALLreg  00000000             1 

15
_ksdpcg+238          CALLrel  _ksddoa+0            A9615C0 93C78C0 

16
_ksdpec+230          CALLrel  _ksdpcg+0            674 C04A478 1 

17
__PGOSF89__ksfpec+1  CALLrel  _ksdpec+0            674 

18
18                                                  

19
_kgesev+88           CALLreg  00000000             A0C6760 674 

20
_ksesec2+39          CALLrel  _kgesev+0            A0C6760 93C0020 674 2 C04A4E4 

21
_ktsxterr+316        CALLrel  _ksesec2+0           674 0 80 0 1 E C04A55E 

22
_ktfbtgex1+969       CALLrel  _ktsxterr+0          792DE5C 80 0 

23
_ktsxs_add+1766      CALLrel  _ktfbtgex1+0         C04AD8C 3D C04AA50 80 18 A 3 

24
                                                   0 0 C04AD50 37B3EE88 

25
_ktsxssr_sadd+1409   CALLrel  _ktsxs_add+0         C04B048 C04AD8C 80 A 3 0 18 1 

26
                                                   C04B11C C04AE08 C04ADC0 0 

27
                                                   C04AD50 

28
_ktrsexec+372        CALL???  00000000             C04B0D8 

29
_ktelwbl+770         CALLrel  _ktrsexec+0          C04B0D8 

30
_kdblba+168          CALLrel  _ktelwbl+0           792DE5C 1 

31
_kdblGetBlockDba+58  CALLrel  _kdblba+0             

32
_kdblgb+26           CALLrel  _kdblGetBlockDba+0   C04B3C8 792DD9C 

33
_kdblailb+2101       CALLrel  _kdblgb+0             

34
_kdblai+1560         CALLrel  _kdblailb+0          C04B3C8 792DC9C 792DD9C 0 1 1 

35
_klclil1r+187        CALLrel  _kdblai+0             

36
_qerltRop+514        CALLrel  _klclil1r+0          792DBEC 

37
_qercbiFetch+935     CALLreg  00000000             34C4F034 7FFF 

38
_rwsfcd+95           CALL???  00000000             34C4F384 1C72EB4 34C4F034 

39
                                                   7FFF 

40
_qerltFetch+368      CALL???  00000000             34C4F148 1C72EB4 34C4F034 

41
                                                   7FFF 

42
_ctcdrv+7674         CALL???  00000000             34C4F034 1D28394 C04CE30 1 

43
_opiexe+12257        CALLrel  _ctcdrv+0            34EE5F50 C04D548 C04D510 

44
_opiosq0+6088        CALLrel  _opiexe+0            4 0 C04D8C0 

45
_kpooprx+232         CALLrel  _opiosq0+0           3 E C04D9D8 A4 

46
_kpoal8+775          CALLrel  _kpooprx+0           C04F6F8 C04E224 6D 1 0 A4 

47
_opiodr+1099         CALLreg  00000000             5E 17 C04F6F4 

48
_ttcpip+1273         CALLreg  00000000             5E 17 C04F6F4 0 

49
_opitsk+1017         CALL???  00000000              

50
_opiino+1087         CALLrel  _opitsk+0            0 0 

51
_opiodr+1099         CALLreg  00000000             3C 4 C04FC8C 

52
_opidrv+819          CALLrel  _opiodr+0            3C 4 C04FC8C 0 

53
_sou2o+45            CALLrel  _opidrv+0            3C 4 C04FC8C 

54
_opimai_real+112     CALLrel  _sou2o+0             C04FC80 3C 4 C04FC8C 

55
_opimai+92           CALLrel  _opimai_real+0       2 C04FCB8 

56
_OracleThreadStart@  CALLrel  _opimai+0             

57
4+708                                               

58
7C80B710             CALLreg  00000000

ErrorStack 덤프는 그 레벨에 따라 다양한 유용한 정보를 제공해줍니다. 아래 아티클에서 상세한 정보를 얻을 수 있습니다.

http://tech.e2sn.com/oracle/troubleshooting/how-to-read-errorstack-output

출처 : http://ukja.tistory.com/307

저작자표시 (새창열림)

'Database > ORACLE' 카테고리의 다른 글

DB에 Connect 할수 없을 때의 진단 - Case Study(Library Cache Latch Contention) (0)	2010.03.26
Oradebug 사용법 (0)	2010.03.26
간단한 방법으로 SID 변경하기 (nid 사용) (0)	2010.03.15
Oracle SID error (0)	2010.02.09
rman Tool (0)	2010.02.01

올해 30세 초반인 필자는

용인으로 신혼집을 정했으니....

문제는 서울에 온지는 3년이 넘었으나... 방배동 <-> 삼성역 간의 길 밖에 모른다는 것입니다...

더구나... 청담역 <-> 삼성역 간의 버스를 제외하곤 버스를 탈일이 없었습니다....

우선 급한 불인 신혼집을 구하고 나니... 헉... 고속버스를 타고 무조건 와야 하나 어찌나 걱정이 되던지...

긴 한숨에 걱정만 태산이었습니다...

주위의 사람들에게 물어도 서울 버스 노선은 대부분 자기가 타는 노선만 기억하고 타고 다니고 있더군요...

우짜지... 머리속은 깜깜해 졌고...

물론 인터넷 검색을 해봐도

용인에서 삼성역까지 빠른길 ... 오는 방법.... 최단 거리... 아침에 출근하기 좋은 방법...

별의별 검색을 해봐도 찾기란... 에휴....

그러다가

경기도 버스 정보 시스템 사이트가 존재하는 것을 알게 되었고

쉽게 노선을 검색하는 방법을 찾게 되었네요.

경기도 버스 정보 시스템 사이트 주소 : http://www.gbis.go.kr/

노선 검색

메인 화면 -> 실시간 검색 -> 노선 검색의 화면입니다.

통합 검색 메뉴에는
1. 노선번호 2. 건물명 3. 정류소 번호 4. 정류소명 4개의 선택 박스가 존재한다.
가장 먼저 노선번호는 우리가 볼수 있는 버스의 번호이다. 아래는 용인 <-> 강남역 구간을 운행하는 5002 번 노선을 검색한 결과이다.

검색결과를 보면 5002번에 대해 용인, 서울 이라는 검색 결과가 나오며 상세보기를 클릭하면 아래와 같은 화면을 볼수 있다.

검색결과 아래를 보면 실제 정류장도 확인 할 수 있어 어디서 타야 하는지 정확하게 알수 있습니다.

또한 그아래에 보면 배차 간격과 첫차 시간등을 알수 있어 매우 유익 합니다.

더 자세한 내용은

서비스 이용안내를 누르면 바로 확인 가능합니다.

저작자표시 (새창열림)

고객사에서 아래의 작업이 매 주 일어납니다.

1. 운영 DB서버의 컨트롤/리두로그/데이터 파일 부분을 테스트 DB서버로 이미지카피를 합니다.

(DB 엔진부분이나 설정파일은 복사하지 않습니다.)

2. 테스트 DB의 SID를 테스트에 맞게 변경해줍니다.

예전같으면 벌벌떨면서 진행했던 SID 변경 작업이지만,

10.x 이상의 버젼에서 nid라는 도구가 도입되면서 아주 간단한(실수를 하지 않는다면) 작업으로 변했습니다.

아래는 변경 절차입니다.

운영 DB서버의 SID는 PROD, 테스트 DB서버의 SID는 TEST라고 하겠습니다.

##########################################################################

이미지 카피가 정상적으로 되어 DB가 정상적으로 올라오는지 확인하는 부분

##########################################################################

1) 이미지카피가 완료된 후....

2) .profile에 설정되어 있는 SID를 PROD로 변경합니다.

3) . .profile로 변경된 사항을 적용합니다.

4) cp inittest.ora initprod.ora 명령으로 기 존재하는 파라메터 파일을 이용하여 초기화 파라메터 파일을 생성합니다.

5) 생성한 initprod.ora 파일을 열어서, controlfile의 위치를 실제 파일이 위치하는 곳으로 변경하고..

db_name 파라메터를 prod로 변경하고..

local listener 파라메터 설정 부분을 remark 합니다.

6) 패스워드 파일 사용중이라면 orapwd 명령으로 패스워드 파일을 생성합니다.

7) sqlplus 에 로그인하고, startup 명령으로 DB를 살려서 정상적으로 올라오는지 확인합니다.

##########################################################################

SID을 바꾸고 DB가 정상적으로 올라오는지 확인하는 부분

##########################################################################

8) DB가 정상이라면 shutdown 명령으로 DB를 내립니다.

9) DB를 Mount 단계까지 올립니다.

10) 다른 창을 하나 띄워서 아래의 명령어로 SID를 변경합니다.

nid target=sys/<패스워드> dbname=TEST setname=yes

(nid가 실행되면 nid가 Mount되어 있는 DB를 shutdown 시킵니다.)

<실제 수행 화면>

[oracle@sbiztdb1:prod:/sks1/oracle]nid target=sys/<패스워드> dbname=TEST setname=y

DBNEWID: Release 10.2.0.4.0 - Production on Sat Jun 13 22:53:29 2009

Connected to database PROD (DBID=3426403114)

Connected to server version 10.2.0

Control Files in database:
    /dev/hdvg21/rlvol_0500M0001
    /dev/hdvg22/rlvol_0500M0006
    /dev/hdvg23/rlvol_0500M0011

Change database name of database PROD to TEST? (Y/[N]) => Y

Proceeding with operation
Changing database name from PROD to TEST
    Control File /dev/hdvg21/rlvol_0500M0001 - modified
    Control File /dev/hdvg22/rlvol_0500M0006 - modified
    Control File /dev/hdvg23/rlvol_0500M0011 - modified
    Datafile /dev/hdvg21/rlvol_4000M0001 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0002 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0008 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0042 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0009 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0003 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0004 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0005 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0006 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0007 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0008 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0009 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0011 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0012 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0013 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0014 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0015 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0016 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0017 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0018 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0019 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0020 - wrote new name
    Datafile /dev/hdvg23/rlvol_8000M0021 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0022 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0023 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0024 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0025 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0026 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0027 - wrote new name
    Datafile /dev/hdvg24/rlvol_8000M0028 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0030 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0031 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0032 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0034 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0035 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0036 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0037 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0038 - wrote new name
    Datafile /dev/hdvg21/rlvol_4000M0002 - wrote new name
    Datafile /dev/hdvg21/rlvol_4000M0003 - wrote new name
    Datafile /dev/hdvg21/rlvol_4000M0004 - wrote new name
    Datafile /dev/hdvg21/rlvol_4000M0005 - wrote new name
    Datafile /dev/hdvg21/rlvol_4000M0007 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0008 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0009 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0010 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0011 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0013 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0015 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0040 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0041 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0042 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0043 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0044 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0045 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0047 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0049 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0050 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0051 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0017 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0001 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0003 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0010 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0012 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0014 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0016 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0018 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0019 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0020 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0021 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0019 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0020 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0022 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0022 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0023 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0054 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0053 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0055 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0056 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0023 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0024 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0026 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0027 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0028 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0029 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0030 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0031 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0033 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0034 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0035 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0036 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0024 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0025 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0005 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0058 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0059 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0060 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0061 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0062 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0063 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0064 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0038 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0039 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0040 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0041 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0047 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0048 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0049 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0050 - wrote new name
    Datafile /dev/hdvg21/rlvol_1000M0001 - wrote new name
    Datafile /dev/hdvg21/rlvol_1000M0002 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0026 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0027 - wrote new name
    Datafile /dev/hdvg21/rlvol_1000M0003 - wrote new name
    Datafile /dev/hdvg21/rlvol_1000M0004 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0006 - wrote new name
    Datafile /dev/hdvg24/rlvol_2000M0028 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0029 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0066 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0067 - wrote new name
    Datafile /dev/hdvg21/rlvol_1000M0005 - wrote new name
    Datafile /dev/hdvg21/rlvol_1000M0006 - wrote new name
    Datafile /dev/hdvg21/rlvol_4000M0006 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0044 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0052 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0069 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0070 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0048 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0054 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0055 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0043 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0070 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0033 - wrote new name
    Datafile /dev/hdvg25/rlvol_8000M0029 - wrote new name
    Datafile /dev/hdvg26/rlvol_8000M0039 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0018 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0021 - wrote new name
    Datafile /dev/hdvg24/rlvol_4000M0025 - wrote new name
    Datafile /dev/hdvg26/rlvol_4000M0037 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0045 - wrote new name
    Datafile /dev/hdvg27/rlvol_4000M0046 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0030 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0032 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0033 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0056 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0057 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0058 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0059 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0060 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0061 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0062 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0012 - wrote new name
    Datafile /dev/hdvg22/rlvol_4000M0014 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0002 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0051 - wrote new name
    Datafile /dev/hdvg29/rlvol_4000M0063 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0004 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0034 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0035 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0036 - wrote new name
    Datafile /dev/hdvg23/rlvol_4000M0016 - wrote new name
    Datafile /dev/hdvg22/rlvol_1000M0007 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0037 - wrote new name
    Datafile /dev/hdvg22/rlvol_8000M0010 - wrote new name
    Datafile /dev/hdvg21/rlvol_2000M0007 - wrote new name
    Datafile /dev/hdvg25/rlvol_4000M0032 - wrote new name
    Datafile /dev/hdvg28/rlvol_4000M0053 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0011 - wrote new name
    Datafile /dev/hdvg22/rlvol_2000M0013 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0015 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0064 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0065 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0066 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0067 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0069 - wrote new name
    Datafile /dev/hdvg30/rlvol_4000M0068 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0038 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0039 - wrote new name
    Datafile /dev/hdvg23/rlvol_2000M0017 - wrote new name
    Datafile /dev/hdvg25/rlvol_2000M0031 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0040 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0041 - wrote new name
    Datafile /dev/hdvg26/rlvol_2000M0042 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0043 - wrote new name
    Datafile /dev/hdvg28/rlvol_1000M0044 - wrote new name
    Datafile /dev/hdvg28/rlvol_1000M0045 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0044 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0045 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0046 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0047 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0048 - wrote new name
    Datafile /dev/hdvg27/rlvol_2000M0049 - wrote new name
    Datafile /dev/hdvg28/rlvol_2000M0050 - wrote new name
    Datafile /dev/hdvg28/rlvol_2000M0051 - wrote new name
    Datafile /dev/hdvg28/rlvol_2000M0052 - wrote new name
    Datafile /dev/hdvg28/rlvol_2000M0053 - wrote new name
    Datafile /dev/hdvg28/rlvol_2000M0054 - wrote new name
    Datafile /dev/hdvg28/rlvol_2000M0055 - wrote new name
    Datafile /dev/hdvg21/rlvol_8000M0001 - wrote new name
    Datafile /dev/hdvg27/rlvol_8000M0046 - wrote new name
    Datafile /dev/hdvg28/rlvol_8000M0052 - wrote new name
    Datafile /dev/hdvg29/rlvol_8000M0057 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0065 - wrote new name
    Datafile /dev/hdvg30/rlvol_8000M0068 - wrote new name
    Control File /dev/hdvg21/rlvol_0500M0001 - wrote new name
    Control File /dev/hdvg22/rlvol_0500M0006 - wrote new name
    Control File /dev/hdvg23/rlvol_0500M0011 - wrote new name
    Instance shut down

Database name changed to TEST.
Modify parameter file and generate a new password file before restarting.
Succesfully changed database name.
DBNEWID - Completed succesfully.

11) .profile에 설정되어 있는 SID를 TEST로 변경합니다.

12) sqlplus 에 로그인하고, startup 명령으로 DB를 살려서 정상적으로 올라오는지 확인합니다.

(pfile을 가지고 spfile을 생성한 후 다시 startup하여 spfile로 DB가 운영되도록 수정합니다.)

   SQL>startup pfile=inittbizdb.ora
   SQL>create spfile from pfile;
   SQL>shutdown immediate
   SQL>startup

13) 아무런 문제가 없다면 작업 종료...

일반적으로 SID만 변경하시는 분들은 8)부터만 수행하시면 됩니다. 1)~7)까지는 이미지카피 후 정합성 확인하는 부분입니다.

좀 더 자세한 내용은 nid로 오라클 사이트에서 검색하시면 찾으실 수 있을 겁니다....

업무에 도움이 되셨길 빕니다....^^

[출처] 간단한 방법으로 SID 변경하기 (nid 사용) (ProDBA) |작성자 바람숨결

저작자표시 (새창열림)

'Database > ORACLE' 카테고리의 다른 글

Oradebug 사용법 (0)	2010.03.26
ErrorStack 덤프를 이용해 문제 SQL 찾아내기 (0)	2010.03.26
Oracle SID error (0)	2010.02.09
rman Tool (0)	2010.02.01
WS1-2-ch18. Data Pump (expdp/impdp) overview (0)	2010.02.01

모바일 프로그램중 닷넷 프레임 워크 3.5를 요구하는 프로그램들이 있다....

지하철 도착시간 알리미 이 프로그램을 설치하고

실행도중 오류가 발생하였다.

원인은 닷넷 프레임 워크 3.5를 안깔아서 그랬다...

설치 방법

1. 아래의 주소에서 재배포 가능 NetCFSetupv35.msi 파일을 다운 받는다.

모바일 .NET Compact Framework 3.5 재배포 가능 패키지 다운로드 주소

http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=e3821449-3c6b-42f1-9fd9-0041345b3385

2. 컴퓨터와 옴니아2 기종을 연결한다.
이때 Active Sync가 가동된다.

3. 다운받은 .msi 파일을 컴퓨터상에서 실행한다.

4. 연결된 옴니아2를 보면 설치화면이 나오고 바로 설치한다.

끝 !

저작자표시 (새창열림)

'Mobile Phone' 카테고리의 다른 글

갤럭시 S2 이메일 비밀번호 변경 하기 (0)	2012.02.13
스마트튠 PC 용 (0)	2011.06.30
옴니아2 고스톱 맞고 브루마블 2종 세트 (0)	2010.01.12
옴니아 2 배경 화면 ~ (0)	2009.12.10
옴니아 2 PC Studio 설치버젼 (0)	2009.12.01

출처 : www.acrobatpdf.com

저작자표시 (새창열림)

'UTILITY > Acrobat' 카테고리의 다른 글

무료 PDF 변환 프로그램 (0)	2011.03.31
애크로뱃 숨은 기능 찾기 : PDF도 편집이 된다(2) (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라하는 다이나믹 독도 PDF 포트폴리오 제작(2) (0)	2010.03.09
애크로뱃 숨은 기능 찾기 : PDF도 편집이 된다(1) (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라 하는 다이나믹 독도 PDF 포트폴리오 제작 (1) (0)	2010.03.09

저작자표시 (새창열림)

'UTILITY > Acrobat' 카테고리의 다른 글

무료 PDF 변환 프로그램 (0)	2011.03.31
[애크로뱃 3분 따라하기] 새는 정보 꼭꼭 숨기는 PDF 속의 철통 보안 (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라하는 다이나믹 독도 PDF 포트폴리오 제작(2) (0)	2010.03.09
애크로뱃 숨은 기능 찾기 : PDF도 편집이 된다(1) (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라 하는 다이나믹 독도 PDF 포트폴리오 제작 (1) (0)	2010.03.09

저작자표시 (새창열림)

'UTILITY > Acrobat' 카테고리의 다른 글

[애크로뱃 3분 따라하기] 새는 정보 꼭꼭 숨기는 PDF 속의 철통 보안 (0)	2010.03.09
애크로뱃 숨은 기능 찾기 : PDF도 편집이 된다(2) (0)	2010.03.09
애크로뱃 숨은 기능 찾기 : PDF도 편집이 된다(1) (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라 하는 다이나믹 독도 PDF 포트폴리오 제작 (1) (0)	2010.03.09
[애크로뱃 3분 따라하기] 출장 시 꼭 알아야 할 온라인 커뮤니케이션 노하우 (0)	2010.03.09

저작자표시 (새창열림)

'UTILITY > Acrobat' 카테고리의 다른 글

애크로뱃 숨은 기능 찾기 : PDF도 편집이 된다(2) (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라하는 다이나믹 독도 PDF 포트폴리오 제작(2) (0)	2010.03.09
[애크로뱃 3분 따라하기] 쉽게 따라 하는 다이나믹 독도 PDF 포트폴리오 제작 (1) (0)	2010.03.09
[애크로뱃 3분 따라하기] 출장 시 꼭 알아야 할 온라인 커뮤니케이션 노하우 (0)	2010.03.09
[애크로뱃 3분 따라하기] 고객을 감동시키는 제안서, 다이내믹 PDF로 제작하기 (0)	2010.03.09

웹 개발과 관련된 모든 것들