# 헤더파일 추가

1. Go to project->build options.

2. "search directories"

3. "compilers" sub tab.

4. Click add, select the file and you are done.

# 라이브러리 추가

1. 글로벌 Settings

2. Compiler

3. Linker Settings

4. Click add, select the file and you are done.

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

ERROR:

ORA-28040: No matching authentication protocol

# sqlnet.ora 파일에 아래와 같이 한줄 추가

SQLNET.ALLOWED_LOGON_VERSION = 9

QT를 이용하여 오라클 데이터베이스에 접속하는 프로그램을 만들고자 할 경우 QOCI, QODBC 등의 방법으로 접속을 할수 있습니다.

저의 테스트 환경인 QT 5.9 버전에서는 QOCI에 대한 SQL Database Drivers는 제공되지 않기 때문에 직접 생성하여 사용해야합니다.

1. 환경 변수 설정

QTDIR=C:\Qt\Qt5.9.0\5.9\mingw53_32\bin

#### mingw32-make.exe를 사용하기 위한 환경변수의 PATH에 추가

C:\Qt\Qt5.9.0\Tools\mingw530_32\bin

#### 적용 예 : PATH=%PATH%;%QTDIR%\bin;C:\Qt\Qt5.9.0\Tools\mingw530_32\bin

2. cmd.exe를 실행하여 아래와 같이 컴파일 진행

set INCLUDE=%INCLUDE%;N:\app\product\11.2.0\client_1\oci\include

set LIB=%LIB%;N:\app\product\11.2.0\client_1\oci\lib\msvc

set QMAKE_DEFAULT_INCDIRS=N:\app\product\11.2.0\client_1\oci\include

qmake oci.pro

mingw32-make

정상적으로 빌드가 될 경우

C:\Qt\Qt5.9.0\5.9\Src\qtbase\plugins\sqldrivers 경로에 qsqloci.dll, qsqlocid.dll 파일이 생성됨.

3. qmake로 컴파일 진행 중 아래 에러가 발생할 경우

- ERROR : Project ERROR: Library 'oci' is not defined.

#### oci.pro 파일의 원본을 열어서 수정 해야함.

------------------------------------------------------------

TARGET = qsqloci

HEADERS += $$PWD/qsql_oci_p.h

SOURCES += $$PWD/qsql_oci.cpp $$PWD/main.cpp

# QMAKE_USE += oci  >> 오라클 클라이언트에서 제공하는 oci.lib를 이용하여 컴파일을 하였더니 OCI 함수를 못찾는 경우가 발생하여 instant-client의 oci.dll 파일로 대체하여 컴파일 하였음.

QMAKE_LFLAGS += oci.dll

darwin:QMAKE_LFLAGS += -Wl,-flat_namespace,-U,_environ

OTHER_FILES += oci.json

PLUGIN_CLASS_NAME = QOCIDriverPlugin

include(../qsqldriverbase.pri)

------------------------------------------------------------

#### 다시 컴파일 진행 : qmake "LIBS+=-loci" oci.pro

4. mingw32-make로 컴파일 진행 중 아래 에러가 발생할 경우

- ERROR : qsql_oci.cpp:65:17: fatal error: oci.h: No such file or directory

Makefile.Debug / Makefile.Release을 열어서 INCPATH와 LIBS 변수에 오라클의 $ORACLE_HOME/oci/include와 $ORACLE_HOME/oci/msvc 경로를 각각 설정하고 다시 mingw32-make 를 실행함.

5. qsqloci.dll을 생성하기 위한 참조 경로

# oci.pro path

C:\Qt\Qt5.9.0\5.9\Src\qtbase\src\plugins\sqldrivers\oci

# plugin path

C:\Qt\Qt5.9.0\5.9\mingw53_32\plugins\sqldrivers

# OCI HOME

N:\app\product\11.2.0\client_1\oci

# OCI INCLUDE

N:\app\product\11.2.0\client_1\oci\include

# OCI MSVC

N:\app\product\11.2.0\client_1\oci\lib\msvc

# release path

C:\Qt\Qt5.9.0\5.9\Src\qtbase\plugins\sqldrivers

# 참조 페이지 

http://doc.qt.io/qt-5/sql-driver.html#qodbc

https://stackoverflow.com/questions/17601662/how-to-build-qt-qoci-oracle-database-driver-on-windows-with-mingw

http://www.oracle.com/technetwork/topics/winsoft-085727.html

Doc ID 1556954.1

데이터베이스/GI PSU, SPU(CPU), 번들 패치(Bundle Patches) 그리고 패치셋에 대한 패치 번호 일람 (Doc ID 1921876.1)

오라클 9i 이상부터는 spfile이 새로 추가되었고 사용을 권장하고 있습니다.

또한 바이너리 파일이고 사용자가 직접 수정하면 파일이 깨진다는 사실을 오라클을 배운사람들이라면 누구나 잘 알거라고 생각됩니다.

spfile이나 pfile에 대한 정보는 이미 잘 설명된 곳이 있으니 다른 곳을 참조바랍니다.

오라클 파라미터는 일반 파라미터와 밑줄이 하나 있는 Hidden 파라미터가 존재합니다.

그런데 SPFILE로 부터 만들어진 pfile에서 밑줄이 두개있는 파라미터를 보신적이 있으신가요 ?

위와 같은 __XXXX 가 두개 있는 파라미터는 AMM(Automatic Memory Management)와 ASMM(Automatic Shared Memory Management)를 사용할 경우 SGA와 PGA의 할당된 현재 사이즈입니다.

SPFILE을 참조하여 기동 될 경우 자동적으로 할당된 값입니다.

일반적으로 메뉴얼이나 서적에서는 shutdown immediate을 할 경우 모든 세션의 트랜잭션을 정리하고 종료되는 것으로 알고 있을 것입니다. 하지만 항상 예외는 있겠죠?

실제 운영 중인 서버에서 Cold Backup 과정 중 shutdown 이 안되는 상황이 발생하여 찾아보니 3가지 원인이 있는 것을 확인하였습니다.

shutdown 후 alert log를 확인하면 아래 에러를 출력하고 인스턴스가 종료되지 않는 것을 확인할 수 있습니다.

SHUTDOWN: Active sessions prevent database close operation

3가지 원인에 대한 이유와 처리 방법이 소개된 원문과 링크를 참조하시기 바랍니다.

Many times Oracle DBA's are faced with a situation where shutting down the instance with shutdown immediate seems to take infinite time and gives a impression that the session is hung. In most of the cases this is not a hang. Hang can be defined as a scenario when few sessions/processes are waiting on some action and in turn blocking other session/processes to complete their tasks. Now the original sessions could be waiting because of resource issues or Oracle Bugs.

Shutdown immediate can take long time to complete (appear to be hung) because of three reasons:

1. Uncommitted transactions are being rolled back.

2. SMON is cleaning temp segments or performing delayed block cleanouts.

3. Processes still continue to be connected to the database and do not terminate.

1. Uncommitted transactions are being rolled back:

This is the case when the message 'Waiting for smon to disable tx recovery' is posted in the alert log after we issue shutdown immediate.

There are two reasons for this:
- A large query was running at the time of shutdown immediate.
-A large transaction was running at the time of shutdown immediate.

For large queries:

SQL > select count(*) from v$session_longops where time_remaining>0;

If it returns a value > 0 then we can do a shutdown abort and then startup restrict and then again shutdown immediate.

For large transactions:

SQL > select sum(used_ublk) from v$transaction;

If it returns a large value then we have to wait for a long time for shutdowm to get completed.
If the large transaction is aborted and then shutdown is issued then we have to query v$fast_start_transactions and v$fast_start_server, we will not see anything in v$transaction at this time.

At this particular moment transaction recovery is going on and the count(*) will keep on decreasing:

SQL > select count(*) from v$fast_start_transaction;

Decreasing count will show that recovery is going on and when the recovery is completed the database will be shutdown.

But it is not desirable under some circumstances such as, when we have very short maintance window and we need to perform a shutdown immediate to do some work, in those cases we can use the following event and set in the init.ora file TEMPERORARLY To disable transaction recovery:

event="10513 trace name context forever, level 2"

and bounce the instance and issue shutdown immediate to get complete without transaction recovery.SMON will not do a transaction recovery untill this event is set in the init.ora file so it is necessary to remove this event whenever you get a chance to shutdown the database again, this time shutdown immediate can even take 3-5 hours(Just remove this event from pfile).

2. SMON is cleaning temp segments or performing delayed block cleanouts:

During a SHUTDOWN IMMEDIATE and SHUTDOWN NORMAL, SMON cleans up extents which are no longer needed and marking them as freed. It means that count from uet$ will decrease and count in fet$ will increase.

To verify that the temporary segments are decreasing have an active session available in SQL during the SHUTDOWN IMMEDIATE. Run query to ensure the database is not hanging, but is actually perform extent cleanup:

SQL> select count(block#) from fet$;
COUNT(BLOCK)
----------
115

SQL> select count(block#) from uet$;
COUNT(BLOCK)
----------
713

After some time, issue the query again and check the results:

SQL> select count(block#) from fet$;
COUNT(BLOCK)
----------
210

SQL > select count(block#) from uet$;
COUNT(BLOCK)
----------
512

If you do not have sufficient time to wait for this cleanup then you can set the following event and bounce the database and reissue shutdown immediate to skip this cleanup:

event="10061 trace name context forever, level 10"

It allows you to prevent SMON from cleaning up temporary segments. Again it is not recommended to set this event event forever. Whenever you have large downtime remove this event and allow SMON to do its work.

3. Processes still continue to be connected to the database and do not terminate:

After issuing shutdown immediate, If we see entries in alert log file as:

Tue Jan  8 12:00:27 2008
Active call for process 10071 user 'oracle' program 'oracle@server.domain.abc (J001)'
SHUTDOWN: waiting for active calls to complete.
Tue Jan  8 12:00:57 2008

SHUTDOWN: Active sessions prevent database close operation

It shows that there are some active calls at program 'oracle@server.domain.abc (J001)' which pmon is not able to clear up.This message is due to the fact that database is waiting for pmon to clean up processes, but pmon is unable to clean them. The client connections to the server are causing the shutdown immediate or normal to hang. Do the following in this case:

1. Before shutdown immediate, shutdown the listener:

$ lsnrctl stop

2. Now check if there are any connection present at the database as:

$ ps -eaf | grep LOCAL

It will give you the OSPIDs of the client connected to database.

3 Manually kill them as:

# Kill -9 <OSPID>

4. Issue shutdown immediate now.

Do not forget to bring up the listener after startup 

In addition to this you can set 10046 event in the session used to shutdown the instance. This will help to tell the event on which session is waiting

SQL>alter session set events '10046 trace name context forever, level 12'

SQL>Shutdown immediate;

Look for the trace file in user_dump_dest location. Also look at the alert.log for any other messages. They might be helpful in case the shutdown is experiencing hang situation.

참조 링크 : http://askdba.org/weblog/2008/05/shutdown-immediate-hang-2/

오라클 SE와 SE ONE 버전 확인 방법에 대한 질문을 받았습니다.

그래서 몇가지 확인 방법을 정리합니다.

1. EE vs SE

SQL> SELECT * FROM PRODUCT_COMPONENT_VERSION;

엔터프라이즈와 스텐다드 버전에 대해서 명확하게 확인 가능.

2. 접속

prompt# sqlplus /nolog

SQL> select * from v$version ;

접속된 서버의 버전 정보에 나온다고는 하나 SE와 SE ONE에 대해서는 확인 불가. 

3. Cluster 유무

RAC 지원 기능이 활성화되어 있느냐 안되어 있느냐에 따라 확인 가능하다고 하나 true/false로만 판단되어 확인 불가.

혹시나 하여 dba_feature_usage_statistics의 RAC 항목에서도 true/false로만 표현됨.

4. 설치 로그 확인

$ORACLE_BASE/oraInventory/logs/installActions<timestamp>.log 

SE와 SE ONE에 대하여 확실하게 확인 가능함. 하지만 사용자가 로그를 지웠을 경우 확인 불가.

DBMS_XPLAN로 실행 계획을 볼때 PLAN_TABLE is old version이라고 나올 경우 해결법

Note
-----
   - 'PLAN_TABLE' is old version

25 rows selected.

SQL> drop table plan_table;
Table dropped.

SQL> @?/rdbms/admin/utlxplan.sql
Table created.

스크립트 시작 부분에 설정함.

# 오류 발생 시 SQL*Plus를 종료함.(오류 발생 전 변경 내역 commit )

SQL> whenever sqlerror exit sql.sqlcode

# 오류 발생 시 SQL*Plus를 종료함.(오류 발생 전 변경 내역 rollback)

SQL> whenever sqlerror exit rollback sql.sqlcode

윈도우 10 업그레이드 또는 설치 이후 CD-ROM이 인식 안될 경우 다음과 같이 합니다.

여러 가지 방법 중 레지스트리에 보조키를 직접 등록하는 방법으로 CD-ROM을 인식 시키고자 합니다.

1) 관리자 권한으로 명령 프롬프트(cmd.exe) 실행

2) 하단 명령어를 복사하여 붙여 넣기

reg.exe add "HKLM\System\CurrentControlSet\Services\atapi\Controller0" /f /v EnumDevice1 /t REG_DWORD /d 0x00000001

3) 재부팅

※ 참조 : https://support.microsoft.com/en-us/kb/314060

해당 링크에 4가지 CD-ROM 을 복구하는 방법에 대해 설명하고 있으니 편한 방법으로 복구 가능합니다.

앞서 SQL Plan 변경을 위해 SQL Profile, Stored Profile을 잠깐 소개 및 자동화 시킨 부분을 포스트하였습니다.

이번에는 ORACLE 11g에서 새로운 기능으로 제공하는 SPM(SQL Plan Management)을 이용하여 실행계획을 변경하고 고정하는 방법을 소개하려고 합니다.

SPM은 실행계획을 자동으로 관리하고 새로운 실행 계획이 Capture되더라도 검증하여 더 나은 실행 계획을 사용할 수 있도록 해주며 사용자에 의해 Auto와 Manual로 관리할 수 있습니다.

SQL Plan Capture는 optimizer_capture_sql_plan_basline 파라미터(default: false)를 이용하여 자동으로 수집 가능하며 SQL Tuning Set 또는 Cusor Cache로 부터 Capture하는 방식을 제공합니다.

SPM을 이용하여 실행 계획을 변경하는 방법을 요약하면 다음과 같습니다.

위 과정대로 SQL 실행 계획을 자동화한 프로그램으로 한번 바꿔 보도록하겠습니다.

1. DBMS_SPM 패키지 설치 확인

2. 권한 및 파라미터 설정 정보 확인

3. 성능이 좋지 않은 SQL의 Plan Baseline 생성

비효율 SQL을 선택 후 우클릭을 하면 아래와 같은 실행 스크립트가 만들어 지며, SQL*Plus에서 실행하여 SQL 실행 계획이 Capture가 되도록 합니다.

정상적으로 Capture가 이루어지면 DBA_SQL_PLAN_BASELINES 딕셔너리에서 Capture된 SQL들을 확인 할 수 있습니다.

4. Cursor Cache로 부터 성능이 개선된 Plan Baseline 생성

dbms_spm.load_plans_from_cursor_cache 를 이용하여 기존에 생성된 비효율 적인 SQL Plan Baseline의 SQL_HANDLE에 성능이 개선된 SQL 실행 계획을 생성 및 추가 합니다.

동일한 SQL_HANDLE로 새로운 SQL Plan Baseline이 생성되는 것을 확인 할 수 있습니다.

5. 성능이 좋지 않은 SQL의 Baseline을 DISABLE으로 변경

성능이 개선된 SQL Plan Baseline을 사용하기 위해 비효율 SQL의 Plan Baseline을 DISABLE로 변경합니다.

6. 변경된 실행 계획으로 SQL이 실행되는지 확인 

동일한 SQL_HANDLE로 SQL Plan Baseline이 등록되면 다음과 같이 실행 가능한 Baseline의 정보를 확인 할 수 있습니다.

앞서 SQL Plan 변경을 위해 SQL Profile을 잠깐 소개 및 자동화 시킨 부분을 포스트 하였었습니다.

이번 포스트는 SQL 실행계획 변경 방법 중 하나인 Stored Outline을 이용하여 실행계획을 변경하고 고정하는 방법을 소개하려고 합니다.

Stored Outline은 Plan Stability(안정화)를 위하여 9i부터 제공되었으며 11g에서 Deprecated 되었습니다.

그리고 Stored Outline의 자세한 개요나 설명 보다는 사용자가 쉽게 사용할 수 있는 자동화에 기준을 맞춰 작성된 점 참조하시기 바랍니다.

Stored Outline을 이용하여 실행 계획을 변경하는 방법을 요약하면 다음과 같습니다.

위 과정대로 SQL 실행 계획을 자동화한 프로그램으로 한번 바꿔 보도록하겠습니다. .

1. DBMS_OUTLN 패키지 설치 확인

2. 권한 확인

3. 성능이 좋지 않은 SQL의 HASH_VALUE 확인 및 Outline 생성

1) Stored Outline을 만들기 위한 비효율 SQL 확인

2) 만들어진 Stored Outline의 Outline 정보 확인

4. 성능이 개선된 SQL의 HASH_VALUE 확인 및 Outline 생성

1) Stored Outline을 만들기 위해 성능이 개선된 SQL 확인

2) 만들어진 Stored Outline의 Outline 정보 확인

5. 성능이 개선된 Outline을 성능이 좋지 않은 SQL의 Outline으로 변경

성능이 개선된 SQL의 Outline name을 From name으로, 비효율 SQL의 Outline name을 To Name으로 한 후 CONVERT를 하여 성능이 개선된 SQL의 Outline 정보를 비효율 SQL의 Outline으로 변경함.

6. 변경된 실행 계획으로 SQL이 실행되는지 확인

stored outlie을 사용하기 위해서는 use_stored_outlines 파라미터를 설정해줘야합니다.

Hash Join이 Nested Loop Join으로 변경되었고 테이블에 대해 각각 index scan 하고 있으며 정상적으로 Stored Outline 이 동작한다면 Note에 use_stored_outlines 파라미터에 지정한 Catalog의 Outline name을 확인할 수 있습니다.

그리고 DBA_OUTLINES 딕셔너리의 USED 컬럼의 값이 UNUSED에서 USED로 바뀌는 것을 확인할 수 있습니다.

Oracle Database를 운영 중인 DBA분들은 가끔 잘 실행되던 SQL이 비효율적은 실행계획으로 성능이 저하되는 것을 보았을 것입니다.

저도 몇번 경험을 해보았지만 해결 방법은 SQL을 변경하여 AP 서버에 변경된 SQL을 적용하고 WAS를 재시작한 후 변경된 SQL로 실행되는지 확인하는 이런 과정을 거쳐야 합니다. 서비스 시간 중에 이 작업을 하려면 서비스가 중단되어야하는 문제가 있습니다.또는 무식한 방법?이지만 shared_pool을 flush 시키다 보면 원래의 실행 계획으로 언젠가 바뀔 순 있습니다. 하지만 전체 SQL을 다시 parsing하고 shared_pool에 reload 하는 부하가 어마어마하니 권장하지는 않습니다.

이런 이유로 ORACLE은 SQL 문장을 수정하지 않고 SQL Plan을 변경하는 방법을 여러가지 제공하고 있습니다.

그 중 하나인 SQL Profile은 SQL Tuning이 목적으로 제공되며 10g 이상 버전 부터 사용할 수 있습니다.

SQL Profile에 대한 소개는 검색을 통해서 쉽게 찾아 볼 수 있으며 더 자세하게 설명할 자신이 없어 링크로 공유합니다.

http://www.dbguide.net/knowledge.db?cmd=view&boardUid=184184&boardConfigUid=21

https://dioncho.wordpress.com/2009/02/03/how-to-tune-sql-statement-without-changing-text-plan-baseline-version/

SQL Profile을 이용하여 실행 계획을 변경하는 것을 자동화 시켜보았습니다.

SQL Profile을 실행 계획을 변경하기 위한 단계는 다음과 같습니다.

1. DBMS_SQLTUNE 패키지 설치 확인

2. 권한 확인

3. 성능이 좋지 않은 SQL의 SQL_ID와 SQL_FULLTEXT 확인

4. 성능이 개선된 SQL의 SQL ID 확인

5. DBMS_SQLTUNE 패키지의 Hidden Procedure인 import_sql_profile을 이용하여 실행 계획 정보(OUTLINE) 변경.

6. 변경된 실행 계획으로 SQL이 실행되는지 확인

1. DBMS_SQLTUNE 패키지 설치 확인

2. 권한 확인

3. 성능이 좋지 않은 SQL의 SQL_ID와 SQL_FULLTEXT 확인

- 비효율 SQL_ID의 실행 계획

4. 성능이 개선된 SQL의 SQL ID 확인
-성능이 개선된 SQL의 실행계획

5. DBMS_SQLTUNE 패키지의 Hidden Procedure인 import_sql_profile을 이용하여 실행 계획 정보(OUTLINE) 변경.

1) 성능이 개선된 SQL을 더블 클릭하여 From SQL_ID로 설정.

2) 비효율적인 SQL을 더블 클릭하여 To SQL_ID로 설정.

3) From(튜닝 SQL) -> To(비효율 SQL)가 지정된 것을 확인 하고 Convert 버튼 클릭.

4) 정상적으로 변경이 되면 DBA_SQL_PROFILES에 변경 내역을 조회할 수 있음. 

6. 변경된 실행 계획으로 SQL이 실행되는지 확인
- Note에 생성된 SQL Profile의 Name이 사용되고 있는 것을 확인 할 수 있음.

Space Manager를 이용하여 Tablespace, Datafile, ASM Disk의 사용량 정보를 한눈에 볼수 있도록 만들었습니다.

이 화면을 만들면서 dba_free_space에서 recyclebin 조회로 성능이 지연되는 것도 한가지 더 배울수 있었네요.

성능 모니터링 툴의 테이블스페이스 사용량을 보여주는 기능 구현 후 테스트를 진행하다 발견한 현상입니다. 모니터링 툴에는 모래시계가 돌며 전체 프로그램은 느려지며 결과는 안나오고.... 

구현이 잘 못 되었는지 다시 보아도 이상은 없었습니다.

그래서 열심히 검색을 해보니 쿼리기반의 SQL 편집 툴에서도 종종 발생한다고 하여 더 자세히 알아보니 10g 부터 추가된 휴지통 기능이 원인을 제공하고 있었습니다.

테이블스페이스의 여유 공간을 알아보기 위해 DBA_FREE_SPACE를 조회하였는데 응답시간이 느려지면서 모니터링 툴까지 영향을 받고 있었습니다.

메타링크 확인 결과 원인은 2가지로

1. 10g 부터 추가된 휴지통 기능으로 DBA_FREE_SPACE뷰에서 삭제된(버려진) 테이블들의 크기를 조회하기 위해 sys.recyclebin$과 JOIN하는 부분 때문입니다.

SQL> select text from dba_views where view_name='DBA_FREE_SPACE';

TEXT

--------------------------------------------------------------------------------

select ts.name, fi.file#, f.block#,

       f.length * ts.blocksize, f.length, f.file#

from sys.ts$ ts, sys.fet$ f, sys.file$ fi

where ts.ts# = f.ts#

  and f.ts# = fi.ts#

  and f.file# = fi.relfile#

  and ts.bitmapped = 0

union all

select /*+ ordered use_nl(f) use_nl(fi) */

       ts.name, fi.file#, f.ktfbfebno,

       f.ktfbfeblks * ts.blocksize, f.ktfbfeblks, f.ktfbfefno

from sys.ts$ ts, sys.x$ktfbfe f, sys.file$ fi

where ts.ts# = f.ktfbfetsn

  and f.ktfbfetsn = fi.ts#

  and f.ktfbfefno = fi.relfile#

  and ts.bitmapped <> 0 and ts.online$ in (1,4) and ts.contents$ = 0

union all

select /*+ ordered use_nl(u) use_nl(fi) */

       ts.name, fi.file#, u.ktfbuebno,

       u.ktfbueblks * ts.blocksize, u.ktfbueblks, u.ktfbuefno

from sys.recyclebin$ rb, sys.ts$ ts, sys.x$ktfbue u, sys.file$ fi

where ts.ts# = rb.ts#

  and rb.ts# = fi.ts#

  and rb.file# = fi.relfile#

  and u.ktfbuesegtsn = rb.ts#

  and u.ktfbuesegfno = rb.file#

  and u.ktfbuesegbno = rb.block#

  and ts.bitmapped <> 0 and ts.online$ in (1,4) and ts.contents$ = 0

union all

select ts.name, fi.file#, u.block#,

       u.length * ts.blocksize, u.length, u.file#

from sys.ts$ ts, sys.uet$ u, sys.file$ fi, sys.recyclebin$ rb

where ts.ts# = u.ts#

  and u.ts# = fi.ts#

  and u.segfile# = fi.relfile#

  and u.ts# = rb.ts#

  and u.segfile# = rb.file#

  and u.segblock# = rb.block#

  and ts.bitmapped = 0

2. sys.recyclebin$에 삭제된 데이터가 있을 경우.

제 테스트 환경(12.1.0.2.0)에서는 단 2건의 데이터가 있었지만 10초 이상 응답시간이 없었습니다. 

해결 방법은 휴지통을 비우거나 휴지통 기능을 사용 안하는 방법이 있습니다.

1. 휴지통 비우는 방법

사용 방법

SQL> purge recyclebin;

또는 SYSDBA로 전체 휴지통을 비우는 방법이 있습니다.

SQL> purge dba_recyclebin;

2. 휴지통 기능을 사용 안하는 방법(Default : recyclebin = ON)

세션 레벨 : 

SQL> ALTER SESSION SET recyclebin = OFF;

시스템 레벨 : 

SQL> ALTER SYSTEM SET recyclebin = OFF;

참조 : Queries on DBA_FREE_SPACE are Slow (Doc ID 271169.1)

       10g Recyclebin Features and How to Disable it (Doc ID 265253.1)

앞전에 올렸던 ASH Viewer와 연계되어 있던 Plan Viewer의 기능을 대폭 향상하여 Plan Viewer에 대한 데모영상 다시 올립니다.

기존 Plan Viewer의 경우 단순 Tree 형의 Plan만 보여주었지만 이번엔 튜닝을 고려하여 다양한 정보를 볼 수 있도록~

지인께서 고생을 하여주셨습니다.

그래서 Plan Viewer를 이용한 실행계획과 Predicate 정보 등 확인 가능하며, SQL의 시간대별 수행 횟수 및 자원 사용현황 까지~ 한눈에 최대한 볼수 있게 수정되었습니다.

* 실제 운영 서버가 아닌 환경에서 녹화되어 정보가 미흡하지만, 양해 바랍니다~

오라클 AWR의 ASH 기능을 이용한 성능 분석 데모입니다.

개인PC의 DB다 보니 부하가 많이 발생하거나 하지 않아 수집된 데이터 량이 적네요.

시간대별 각 wait_class에 대한 부하를 확인한 후 특정 시간을 설정하면 세션별 SQL 추적을 할 수 있습니다.

각 SQL이 특정 시간 범위에서 차지하는 비율을 확인할 수 있으며 어떤 SQL인지 확인하여 실행계획 확인 후 튜닝을 할 수 있습니다.

(PLAN 뷰어는 아직 개발 중이여서 보여지는 부분이 적지만 추후 다시 올리도록 하겠습니다.)

AWR 보관 주기에 해당하는 날짜를 선택할 경우 선택된 날짜의 ASH 정보 확인을 할 수 있습니다.

로컬PC에 설치된 Virtualbox를 이용하여 6개의 DBMS를 시작한 후 CPU 사용량 및 세션 상태를 확인하는 테스트입니다.

임계치에 따라 신호등과 유사하게 동작하도록 구현되어 있으며 DBMS 장애시 3개의 점멸등이 동시에 켜지게 되어 있습니다.

(테스트에 사용된 로컬PC가 저사양으로 속도는 조금 느립니다.)

## 테스트 서버 사양

▶ 장애 발생 유발 DB

OS : RedHat 6.5 (64bit)

RAM : 1024m

DB : 10g / SID : PERF10

1차 장애 : 유저 프로세스 KILL

2차 장애 : 리스너 & 유저 프로세스 KILL

▶ 일시적 부하 DB

OS : RedHat 6.5 (64bit)

RAM : 1024m

DB : 11g / SID : PERF

▶ 기타 모니터링 대상 DB

OS : CentOS 7 (64bit)

RAM : 1024m

DB : 12c / SID : cdb1, pdb1

OS : Windwos 10 (64bit)

RAM : 8196m

DB : 12c / SID : corcl, orcl

DBA라면 기본적으로 해야하는 일인 실시간 모니터링!

관리하고 있는 DBMS가 어떤 상태인지, 어떤 SQL이 문제가 있는지 또는 발생할 수 있을지 알아보려면 여러가지 툴과 SQL들이 필요합니다.

하지만 상용 툴이 아닌 이상 많은 시간을 투자하여 자기만의 스크립트를 만들고 업무 시 상황에 맞는 스크립트를 찾아 쓰고 하는 불편한 점이 있었습니다.

개인적인 경험으로 익숙해지면 툴 보다 편리하고 빠르다는 장점은 있지만, 고객사를 지원하는 엔지니어성 업무에서는 스크립트 파일들을 생성 또는 업로드하는 이러한 작업이 수월하지는 않았습니다.(괜히 눈치 보이고...ㅠㅠ)

그래서 직접 만들어 볼까? 하는 마음에 하나 만들어 보게 되었습니다.

DBA만 해보신 지인과 개발 부터 시작하여 DBA로 전직한 제가 함께 일할 기회가 생겨서 짬짬히 만든  오라클 모니터링 툴입니다.

이름은 Lune(가칭)이며 타이틀은 Oracle Monitoring Tools로 개발이 되었습니다~

1차 데모 영상은 테스트 삼아 녹화하여 잘 보이진 않지만, 추후 고화질로 다시 올리도록 하겠습니다.

그리고 1차 데모 버전의 경우 UI가 이쁘지 않다는 주위분들의 의견이 있어 아예 새로운 UI로 다시 개발을 하였습니다. 그러니 이번 영상은 참조만 .... _(__)_

javafx 예제 모음 : https://gist.github.com/james-d

자바 멀티쓰레딩 관련 예제 링크

http://www3.ntu.edu.sg/home/ehchua/programming/java/j5e_multithreading.html

오라클 11.2.0.4.0 버전에서 export dump 수행 시 아래와 같은 에러가 발생할 경우 조치 방법

1. 에러

>>> DBMS_AW_EXP: SYS.AW$EXPRESS: OLAP not enabled

>>> DBMS_AW_EXP: SYS.AW$AWMD: OLAP not enabled

>>> DBMS_AW_EXP: SYS.AW$AWCREATE: OLAP not enabled

>>> DBMS_AW_EXP: SYS.AW$AWCREATE10G: OLAP not enabled

>>> DBMS_AW_EXP: SYS.AW$AWXML: OLAP not enabled

>>> DBMS_AW_EXP: SYS.AW$AWREPORT: OLAP not enabled

2. 삭제 방법

SQL> DROP PUBLIC SYNONYM OLAPFACTVIEW; 

SQL> DROP PUBLIC SYNONYM OLAPDIMVIEW;

SQL> DROP PUBLIC SYNONYM DBMS_ODM;

SQL> DELETE FROM SYS.EXPPKGACT$ WHERE PACKAGE = 'DBMS_AW_EXP'  AND SCHEMA= 'SYS';

SQL> COMMIT;

SQL Server 성능모니터링 툴 : SQL Live Monitor( https://sqlmonitor.codeplex.com/ )

codeplex에 오픈 소스로 공개되어 있는 툴이며 SQL Server의 실시간 모니터링이 가능하다.

보통은 윈도우의 성능모니터링 툴을 이용하여 SQL Server 관련 성능 카운터를 추가하여 모니터링을 해야하지만

SQL Live Monitor의 경우 GUI에 주요 성능 카운터에 대한 지표를 실시간으로 모니터링 할 수 있게 제공하고 있음.

용량도 약 100K 미만으로 엄청 가볍고 csv 파일 형태로 저장도 해주므로 지표 수집 후 서버 성능 분석에도 도움이 될듯 하다.

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

Description

a .NET application that provides realtime performance data on the target SQL Server instance.

No installation required, data displayed in realtime, and can also be logged to CSV for offline analysis. Will also capture SQL data for processing uing PAL.

Features

This tool is designed to provide realtime performance data on SQL Server, as well as data capture for offline analysis. The tools features are:

• Realtime SQL and System performance data
• Colour coded alerts
• Capture data logging to CSV - sample interval configurable
• PAL Perfmon counter logged to .blg or .csv for offline analysis using PAL - sample interval configurable
• Detailed view of certain SQL Areas via DMVs
• List Top 20 Queries by CPU, IO and Execution Count
• View SQL Waits by category
• View SQL Scheduler and CPU worker threads
• Monitor Kernel Pools and System PTE's
• Supports SQL 2000,SQL 2005, SQL 2008, SQL 2012, SQL 2014
• Captures data from local and remote servers
• Captures data from default and named instances (stand alone & clustered)
• Supports both SQL and Windows Authetication
• Supports x86 and x64
• No installation required
• Application small in size with minimal overhead when running
• Run multiple instances on same PC

Last edited Jun 17, 2014 at 4:59 PM by glensmall, version 12

갑작스레 MSSQL 성능 모니터링 지원 요청으로 몇가지 찾아보다 참조자료가 있어서 퍼옴.

열심히 구글링을 하다가 내용만 복사했더니.... 원문 링크를 잃어 버리다니....ㅠ

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

MS-SQL을 사용하는 DB서버의 속도가 느려진다거나 성능 저하가 느껴질때

물리적인 서버의 성능을 테스트하여 성능향상을 고려할수 있습니다. 논리적인부분 배제함

1. CPU

성능모니터링을 이용한 CPU 모니터링

% Processor Time : 80% 이하가 정상 

% Privileged Time : 80% 이하가 정상 

% User Time : 80% 이하가 정상 

Processor Queue Length : 2 이하가 정상 

비정상 수치의 대책 : 프로세서 추가, 더빠른 프로세서로 교체, 보다많은 캐쉬 확보

2. 메모리

성능모니터링을 이용한 메모리 모니터링 

Available Bytes : 4 메가 이상이 정상 

Pages/sec (paging in/out) : 0~20일 때 정상

Page Reads/sec : 5 이하가 정상 

Page Writes/sec : 5 이하가 정상 

Buffer Cache Hit Ratio : 90% 이상이 정상 

비정상 수치의 대책 : 메모리 추가

3. 디스크

성능모니터링을 이용한 디스크 모니터링

검사항목 

% Disk Read Time : 40% 이하가 정상 

% Disk Write Time : 40% 이하가 정상 

% Disk Time : 40% 이하가 정상 

Avg. Disk Queue Length : 2 이하가 정상 

비정상 수치의 대책 : 디스크 추가 , RAID 고려, 서버교체를 통한 고속의 신형HDD로의 교체

오라클의 fast recovery area를 disable 하고 archive log 모드에서 기본 경로가 아닌 다른 directory에 archive log를 저장할 경우 RMAN을 이용한 백업 시 archive log 파일을 못찾는 에러가 발생함.

1. 에러 예제

RMAN> backup archivelog all ;

Starting backup at 14-OCT-14
current log archived
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/14/2014 01:12:43
RMAN-06059: expected archived log not found, loss of archived log compromises recoverability
ORA-19625: error identifying file /u01/oracle/product/flash_recovery_area/INNIDB/archivelog/2014_10_01/o1_mf_1_21_b2qyqgpg_.arc
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

2. 해결 방법

RMAN> change archivelog all crosscheck ;

** 주의

위와 같은 방법으로 설정을 한다면 백업 시 backupset이 저장되는 디렉토리는 $ORACLE_HOME/dbs에 저장

HP-UX의 주변장치 확인

1. 하드디스크 확인

# ioscan -fnC disk

2. 테입 확인

# ioscan -fnC tape

3. Network 카드 확인

# ioscan -fnC LAN

4. Fiber Channel 확인

# ioscan -fnC FC

Redo log 장애 - 1개의 member가 삭제되는 장애가 발생하는 경우

# 처리 순서

1. redo log file 상태 확인

set line 200

col group# for 999

col mb for 999

col member for a45

col seq# for 999

col status for a8

col arc for a5

select a.group#,a.member,b.bytes/1024/1024 MB, b.sequence# "SEQ#",b.status, b.archived "ARC"

from v$logfile a, v$log b

where a.group# = b.group#

order by 1,2

/

2. alert log에서 에러 확인

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: '/dbms/oracle/product/oradata/SOLEXTDEV/redo01_a.log'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

3. 에러가 발생한 redo log file memeber 삭제

alter database drop logfile member '/dbms/oracle/product/oradata/SOLEXTDEV/redo01_a.log' ;

4. 신규 redo log file memeber 추가

alter database add logfile member '/dbms/oracle/product/oradata/SOLEXTDEV/redo01_a.log' to group 1 ;

5. redo log file 상태 확인

select a.group#,a.member,b.bytes/1024/1024 MB, b.sequence# "SEQ#",b.status, b.archived "ARC"

from v$logfile a, v$log b

where a.group# = b.group#

order by 1,2

오라클 백업과 복구(서진수 저) 중에서 ...

# 참조 : http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo003.htm

# 신규 redo log group 생성(default)

ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M ;

# 신규 redo log group 생성(group number 지정)

ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M ;

# redo log member 추가

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

# redo log 파일로 member  추가

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo') ;