티스토리 뷰

기술이야기

Oracle JDBC Driver

novathinker 2009.05.26 19:06

 

1) JDBC Driver

- JDBC는 관계형 데이터베이스를 접근하기 위한 표준 API를 의미

- 다양한 DBMS 벤더들은 각자의 방식으로 DBMS에 접근하고 사용해야만 했었으나 Java진영에서는 표준 API를 정하여 각 벤더들로 하여금 이를 구현하게 함

- 이것을 JDBC라고 하고 이를 구현한 것이 JDBC Driver로 각 벤더들은 표준 API와 함께 각자 이를 확장한 나름의 API도 제공하고 있음

- 표준 JDBC API는 java.sql과 javax.sql 두 개의 package로 구성되어 있음

- java.sql은 database에 접근하고 정보를 열람 및 저장 할 수 있는 핵심 JDBC API를 제공

- javax.sql은 JDBC client가 server-side의 data source를 접근할 수 있게 해 주는 API들을 제공

- Oracle의 핵심 JDBC는 oracle.jdbc와 oracle.sql 두 개의 package를 구현함

- oracle.jdbc : 이 package는 java.sql과 javax.sql를 확장하여 구현

- oracle.sql : 이 package는 SQL data type과 매핑할 수 있는 interface와 class를 제공

 

- JDBC driver는 다음의 4가지 형태로 구현이 되어 있음

- Type 1 : ODBC와 같은 다른 data access API와 매핑하는 형태의 JDBC API를 구현한 것으로 이는 native client library에 종속적이 되는 경우가 많아 이식성에 제약이 있음. Sun 의 JDBC-ODBC bridge driver가 이에 속하지만 JDBC3.0의 지원이나 멀티스레딩을 사용할 수 없다는 등의 여러가지 제약을 가지고 있음.

- Type 2 : native code와 Java Code 가 혼재되어 구현이 되어 있는데 주로 Interface만 java인 경우가 많고 접근하는 data source에 따라 각기 다른 native client library가 필요하게 됨. 그래서 이를 thick driver라고도 함. Native code로 인하여 이식성에 제한이 있음

- Type 3 : database에 독립적인 protocol을 이용하는 미들웨어 서버와 통신하는 순수한 java 클라이언트를 사용하는 driver로 미들웨어 서버는 클라이언트의 요청을 data source에 독립적인 프로토콜로 변환하여 사용. 이 경우 driver가 직접 database를 제어하지 않고 미들웨어를 통하여 제어하기 때문에 유연함

- Type 4 : 모두 Java로 구현되어 있어 플랫폼에 제한을 받지 않으며 별도의 클라이언트 소프트웨어 없이 표준 java 소켓을 이용하여 data source와 직접 통신. 보통 thin driver로 표현

- Oracle JDBC Driver : Oracle은 두 개의 Client-side driver와 두 개의 Server-side driver를 제공

- Client-side driver는 database 외부에서 applet, servlet과 같은 형태의 Application으로 JDBC를 수행할 때 사용하고 server-side driver는 database내의 java object에서 사용하게 됨

- Client-side에는 JDBC thin driver(Type 4)와 JDBC OCI driver(Type 2)가 있음

- Server-side에는 JDBC server-side thin driver (Type 4)와 JDBC server-side internal driver(Type 2)가 있음

- 또한 DBMS이외의 벤더가 지원하는 driver도 있음.

- Weblogic의 경우 JDBC thin driver(Type 4)를 제공하는데 이 driver는 DataDirect라는 업체의 DataDirect Connect for JDBC라는 제품을 사용한 것임

- JDBC Thin Driver : Servlet이나 applet과 같은 application에서 Oracle에 접속할 때 사용하며 이 driver는 100% Java로 되어 있기 때문에 플랫폼에 독립적이며 별도의 Oracle 소프트웨어가 필요하지 않음. 이 driver는 TCP/IP 기반의 통신을 하기 때문에 서버는 TCP/IP 리스너로 설정되어 있어야 함

- JDBC OCI Driver : OCI란 Oracle Call Interface의 약자로 C/C++과 같은 3GL언어를 사용하여 Oracle작업을 할 수 있도록 하는 API를 의미. JDBC OCI driver는 Oracle에 특화된 OCI Layer로 감싸져 있어 OCI C 라이브러리, Oracle Net 라이브러리, CORE 라이브러리 같은 파일들이 Client에 있어야 함. OCI driver는 IPC, named pipes, TCP/IP가 포함되어 있는 Oracle Net adapter가 필요함

- JDBC server-side thin driver : server내에서 구동하는 점을 제외하고는 JDBC Thin Driver와 동일하며 code도 동일하다 다만 database내에서 다른 session을 맺는다든가 remote database를 접속할 때 사용됨

- JDBC server-side Thin driver를 사용하여 database의 connection을 얻기 위해서는 Socket을 열어야 하는데 이때 SocketPermission object를 체크하기 때문에 해당 유저는 이 object를 사용하기 위한 권한을 사전에 부여 받아야 함

- JDBC server-side internal driver : java stored procedure와 같은 Oracle내부의 Java Code를 수행할 때 사용할 수 있는데 이는 SQL엔진과 JVM이 직접 통신을 하기 때문에 Network 부하가 전혀 없음

 

 

- 대부분의 경우 Client-side에서 JDBC driver를 이용하여 서비스를 하게 됨

- 보통 JDBC thin Driver를 많이 사용하게 됨. 이는 Platform에 독립적이며 별도의 Client software가 필요 없기 때문에 이식성이 좋기 때문

- 그러나 성능의 측면에서도 JDBC Thin driver가 최적일까에 대한 의문이 생김

- 그래서 Type 2의 JDBC OCI Driver와 Type 4의 JDBC thin Driver 2가지(Oracle, weblogic)의 경우 여러 가지 성능 비교를 수행할 계획임

 

 

2) Test 환경

 

E:\MY WorkPlace\Oracle_Persistence\bin>java -version

java version "1.6.0_01"

Java(TM) SE Runtime Environment (build 1.6.0_01-b06)

Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

 

3) Connection Test

- Oracle JDBC thin Client와 Oracle OCI Client 그리고 Weblogic thin Client의 접속 테스트를 수행

- 시나리오는 100개의 connection을 연속으로 맺게 하여 시간을 측정

- 테스트 결과는 다음과 같으며 시간 단위는 1/100초임

 

go.bat à java app를 구동시키기 위한 batch file

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

@ECHO OFF

java -classpath "E:/oracle/product/10.2.0/db_1/jdbc/lib/ojdbc14.jar;D:/bea/wlserver_10.0/server/lib/wloracle.jar;D:/bea/wlserver_10.0/server/lib/wlbase.jar;D:/bea/wlserver_10.0/server/lib/wlutil.jar;." exem.oracle.JDBCdriver.DoTest %1 %2 %3 %4 %5 %6 %7 %8 %9

===========================

 

E:\MY WorkPlace\Oracle_Persistence\bin>go connection

Connection Time (oci) : 8421

Connection Time (weblogic) : 5984

Connection Time (thin) : 5735

 

- 테스트 결과로 보면 Oracle OCI Driver가 나머지 Driver에 비해 connection을 맺는데 더 많은 시간을 소요하고 있는 것으로 나타났음

- 이는 Type 2와 Type 4의 차이로 보여지며 JVM의 버전이 올라가면서 이제 더 이상 순수 자바코드로 되어 있는 Driver가 늦다고는 할 수 없다고 생각함

- 같은 Type 4의 Driver에서는 Oracle JDBC Thin Driver가 WebLogic에서 제공하는 것보다 근소한 차이로 빠른 것을 나타내고 있음을 알 수 있음.

 

4) Prefetch Test

- Oracle JDBC thin Client와 Oracle OCI Client 그리고 Weblogic thin Client의 Prefetch Test를 수행

- 1,000,000건의 row를 가지고 있는 Prefetch라는 테이블을 모두 가져올 때 각각 fetch size를 default, 100, 600, 1000, 10000로 설정하여 수행

- Test 시나리오는 각 Driver를 fetch size별로 10번씩 수행하여 그 결과를 비교

- 다음은 10회씩 수행한 Total Elapsed Time을 각각 평균 낸 결과임

 

Driver 종류

Fetch Size

TOTAL ELAPSED TIME(초)

oci

default

57.0577

thin

default

56.6579

weblogic

default

14.0093

oci

100

15.8108

thin

100

14.164

weblogic

100

16.6765

oci

600

6.0672

thin

600

4.7672

weblogic

600

10.672

oci

1000

5.3514

thin

1000

3.8408

weblogic

1000

10.0032

oci

10000

4.5733

thin

10000

2.75

weblogic

10000

9.05

 

- default의 경우 Weblogic thin Client가 압도적으로 좋은 성능을 보이고 있음

- 그 이유는 Weblogic thin Client의 default fetch size에 있음

JOSS:oracle:/home/oracle/admin/WASDB/udump:!> grep "FETCH #1" weblogic_0.trc | head -10

FETCH #1:c=2999,e=44392,p=6,cr=6,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051239189

FETCH #1:c=0,e=1045,p=0,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051257213

FETCH #1:c=1000,e=1614,p=8,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051261085

FETCH #1:c=1000,e=776,p=0,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051264054

FETCH #1:c=1000,e=804,p=0,cr=4,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051267333

FETCH #1:c=1000,e=1716,p=7,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051271173

FETCH #1:c=1000,e=798,p=0,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051273529

FETCH #1:c=1000,e=807,p=0,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051276596

FETCH #1:c=999,e=5675,p=8,cr=4,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051284371

FETCH #1:c=1000,e=894,p=0,cr=3,cu=0,mis=0,r=202,dep=0,og=1,tim=1157729051286262

 

-- weblogic_0.trc를 tkprof로 분석한 결과

select *

from

prefetch

 

 

call count cpu elapsed disk query current rows

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

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 4951 4.41 7.35 11570 16462 0 1000000

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

total 4953 4.42 7.36 11570 16462 0 1000000

 

  • 1000000/202 = 4950.5

- 다른 client driver의 default batch size가 10인데 반해 Weblogic thin Client의 default batch size는 202임

- 성능의 차이는 여기에서 기인함

- 모든 경우에서 Oracle JDBC thin Client와 Oracle OCI Client의 차이는 그리 크지는 않으나 Oracle JDBC thin Client가 모두 성능이 더 좋은 것으로 나타남

- 그 밖의 경우 각각 batch size를 설정한 결과는 Oracle JDBC thin Client가 가장 좋은 것으로 나타났고 그 다음은 Oracle OCI Client, 마지막으로는 Weblogic thin Client임

- 이러한 차이가 나타난 원인을 분석해 보기 위해 600건의 fetch size를 설정하여 수행한 10번의 테스트 중 하나를 Oracle Wait, Stat의 기록을 살펴보았음

- 아래는 Wait Event의 일부를 비교한 것

EVENT

Driver 종류

TOTAL WAITS

TIME WAITED

SQL*Net message from client

Oci

1,672

4.84

Thin

1,670

3.53

weblogic

1,678

7.7

SQL*Net more data to client

Oci

4,999

0.06

Thin

4,999

0.06

weblogic

46,357

0.48

- 아래는 Stat의 일부를 비교한 것

STAT

Driver 종류

VALUE

bytes received via SQL*Net from client

oci

20,023

thin

14,094

weblogic

56,483

bytes sent via SQL*Net to client

oci

11,126,377

thin

11,050,347

weblogic

94,473,374

CPU used by this session(cs)

oci

86

thin

93

weblogic

310

SQL*Net roundtrips to/from client

oci

1,672

thin

1,670

weblogic

1,678

session logical reads

oci

13,254

thin

13,259

weblogic

13,256

TOTAL ELAPSED TIME(sec.)

oci

5.813

thin

4.562

weblogic

10.906

USED MEMORY(Bytes)

oci

796,240

thin

1,679,000

weblogic

1,632,472

- 수행 시간 기준으로 비교하면 다음과 같음

 

oci

thin

weblogic

Oracle CPU Time

0.86

0.93

3.1

Oracle Wait Time

4.9

3.59

8.18

Application Time

0.053

0.042

0

 

- 여기서 알 수 있는 것 몇 가지

- 첫째, 다른 Driver와는 달리 Weblogic thin Client의 경우 Oracle의 수행시간인 Session CPU Time이 3배 가량 길게 나타남.

- 이는 세가지 모두 Session logical reads가 거의 동일한 것을 감안한다면 Oracle처리에 있어 어떠한 비효율적인 Operation이 존재한다고 생각할 수 밖에 없음

- 둘째, 전체 수행시간에서 가장 많은 부분을 차지하는 것은 Oracle Wait Time이며 이는 모두Network관련 Wait임

- Oracle과 Application사이의 network roundtrip의 횟수는 모두 비슷하나 Network을 통해 전송되는 데이터량은 상당한 차이가 있음

- Oracle 에서 Application으로 전송되는 데이터량은 Weblogic thin Client가 약 90Mb이고 나머지는 약 10.5MB로 거의 9배에 달하는 차이가 발생함

- Application에서 Oracle로 전송되는 데이터량은 Oracle JDBC thin Client, Oracle OCI Client, Weblogic thin Client가 각각 14KB, 20KB, 55KB로 양 자체는 크지 않지만 Oracle JDBC thin Client와 Oracle OCI Client의 여러 지표들 중 차이가 나는 것이 바로 이 부분인 것으로 보아 전체 수행 시간에도 영향을 미친다고 볼 수 있음

- 셋째 , Application의 메모리 사용은 Oracle OCI Client에 비해 다른 Type4의 Driver가 두배 정도 사용하는 것을 알 수 있음.

 

- 종합해 보면 Prefetch를 사용하지 않는 경우는 Weblogic thin Client를 사용하는 것이 유리하고 만약 Application에서 Prefetch를 설정하여 사용하는 경우는 Oracle Thin Client를 사용하는 것이 유리함

- 이는 Weblogic thin Client내에 batch size를 설정되어 있는 상태이기 때문이고 동등한 batch size를 설정한 경우 Oracle thin Client, Oracle OCI Client의 순서로 성능상의 이점이 많음

- Weblogic thin Client의 경우는 Oracle의 CPU Time도 다른 Driver와 logical reads가 같음에도 불구하고 차이가 나고 있으며 Oracle과 Application의 Network부하도 다른 Driver에 비해 큰 것이 전체 수행 시간의 차이를 보이게 되는 이유로 생각됨

5) Update Batch Test

- Oracle의 Execute횟수를 줄여 성능을 개선하는 기능으로 JDBC내에서 Batch로 모아 여러 건의 작업을 한번의 Oracle Execute를 수행하도록 하는 것임

- 이도 역시 Oracle JDBC thin Client와 Oracle OCI Client 그리고 Weblogic thin Client를 대상으로Test

- 1,000,000건의 row를 가지고 있는 OracleBatch라는 테이블에 동일한 Insert문에 Parameter를 변경하여 각각 1, 100, 2000, 1000, 10000건에 한번씩 execute를 수행하도록 함

- 수행시간 기준 테스트 결과는 다음과 같음

 

TOTAL ELAPSED TIME

APP TIME

DB CPU

DB WAIT

oci_1

753.906

66.836

159.08

527.99

thin_1

793.516

77.536

164.09

551.89

weblogic_1

767.079

72.609

162.6

531.87

oci_10

100.891

6.491

36.53

57.87

thin_10

108.844

7.574

37.53

63.74

weblogic_10

105.25

7.84

36.57

60.84

oci_100

38.313

1.493

20.58

16.24

thin_100

37.656

1.686

20.82

15.15

weblogic_100

37.875

1.545

21.1

15.23

oci_1000

27.438

0.858

18.84

7.74

thin_1000

28.437

0.617

18.79

9.03

weblogic_1000

28.422

0.672

18.88

8.87

oci_10000

28.625

0.365

18.73

9.53

thin_10000

22.906

0.226

18.68

4

weblogic_10000

22.843

0.213

18.8

3.83

- 1건마다 Execute를 한 경우

- Update Batch를 사용한 경우

- 일량 기준의 결과는 다음과 같음

 

roundtrips to/from client

execute count

Data from client(MB)

Data to client(MB)

redo entries

USED MEMORY(MB)

oci_1

1000006

1000200

23.82

76.3

2034467

6.17

oci_10

100006

100198

7.52

7.63

1116540

6.46

oci_100

10006

10204

5.89

0.76

1026252

6.3

oci_1000

1006

1189

5.72

0.08

1020480

7.06

oci_10000

106

338

5.71

0.01

1020709

7.94

thin_1

1000004

1000229

48.62

52.08

2034574

5.52

thin_10

100004

100214

10

5.21

1116601

5.65

thin_100

10004

10240

6.13

0.52

1026379

5.78

thin_1000

1004

1195

5.75

0.06

1020504

5.87

thin_10000

104

292

5.71

0.01

1020540

6.21

weblogic_1

1000013

1000241

36.22

46.36

2034099

1.01

weblogic_10

100013

100205

8.76

4.64

1116553

1.27

weblogic_100

10013

10205

6.01

0.47

1026264

1.36

weblogic_1000

1013

1204

5.74

0.05

1020526

2.14

weblogic_10000

113

304

5.71

0.01

1020560

5.59

 

- 위 테스트를 통해 알 수 있는 사실은 세 Driver모두 일량 부분에 있어서나 수행 시간에 있어서나 큰 차이를 보이지 않는 다는 점

- 그러나 Weblogic thin Client가 가장 적은 Memory를 사용한다는 것은 장점일 수 있음

 

 

6) Statement Cache

- 루프내에서 반복적으로 수행되는 Statement에 대한 Oracle Cursor를 캐시하여 Cursor를 Open되어 있는 상태로 유지함으로써 Parse를 줄이는 효과를 가져옴

- 각 Driver마다 select ? from dual이라는 테이블에 각기 다른 10000건의 파라메터 변수를 바인딩하여 Cache를 사용하는 경우와 사용하지 않는 경우로 나누어 각각 테스트

- 다음은 수행시간 기준 테스트 결과

 

TOTAL ELAPSED TIME

APP TIME

DB CPU

DB WAIT

oci

15.781

0.711

3.3

11.77

thin

14.594

1.184

3.06

10.35

weblogic

21.25

1.58

3.01

16.66

oci_10

7.062

0.172

1.42

5.47

thin_10

7.515

0.335

1.74

5.44

weblogic_10

7.14

0.18

1.54

5.42

 

 

- 일량 기준의 결과는 다음과 같음

 

LIBRARY CACHE LATCHS

parse count (total)

parse time elapsed

SQL*Net roundtrips to/from client

oci

60108

10013

8

20007

thin

60554

10011

11

20005

weblogic

90112

10013

9

30013

oci_10

30096

12

0

10007

thin_10

30545

11

0

10005

weblogic_10

30076

13

0

10015

 

-

select /* oci */ :1

from

dual

 

 

call count cpu elapsed disk query current rows

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

Parse 10001 0.13 0.12 0 0 0 0

Execute 10001 0.90 0.80 0 0 0 0

Fetch 20002 0.10 0.07 0 0 0 10001

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

total 40004 1.14 1.01 0 0 0 10001

 

 

select /* oci_10 */ :1

from

dual

 

 

call count cpu elapsed disk query current rows

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

Parse 1 0.00 0.00 0 0 0 0

Execute 10001 0.76 0.81 0 0 0 0

Fetch 10002 0.24 0.21 0 0 0 10001

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

total 20004 1.00 1.02 0 0 0 10001

 

 

select /* thin */ :1

from

dual

 

 

call count cpu elapsed disk query current rows

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

Parse 10001 0.10 0.12 0 0 0 0

Execute 10001 0.86 0.81 0 0 0 0

Fetch 10001 0.28 0.31 0 0 0 10001

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

total 30003 1.26 1.25 0 0 0 10001

 

 

select /* thin_10 */ :1

from

dual

 

 

call count cpu elapsed disk query current rows

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

Parse 1 0.00 0.00 0 0 0 0

Execute 10001 0.81 0.83 0 0 0 0

Fetch 10001 0.23 0.23 0 0 0 10001

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

total 20003 1.04 1.07 0 0 0 10001

 

 

select /* weblogic */ :v0

from

dual

 

 

call count cpu elapsed disk query current rows

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

Parse 10001 0.16 0.12 0 0 0 0

Execute 10001 0.85 0.83 0 0 0 0

Fetch 10001 0.31 0.31 0 0 0 10001

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

total 30003 1.32 1.27 0 0 0 10001

 

 

select /* weblogic_10 */ :v0

from

dual

 

 

call count cpu elapsed disk query current rows

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

Parse 1 0.00 0.00 0 0 0 0

Execute 10001 0.78 0.82 0 0 0 0

Fetch 10001 0.23 0.23 0 0 0 10001

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

total 20003 1.02 1.05 0 0 0 10001

 

- statement cache를 사용하게 되면 세가지 Driver모두 두 배 이상의 성능 개선 효과를 얻을 수 있고 이 경우 각 driver의 차이는 아주 근소함

- 그러나 테스트 결과 가장 두드러지는 것은 Weblogic thin Client의 성능임

- statement cache를 사용하지 않았을 경우 1번의 parse를 위해 3건의 round trip과 9번의 latch 획득이 필요하며 이는 결국 전체 수행 시간이 길어지는 결과를 초래

- 그러나 statement cache를 사용하자 Oracle JDBC thin Client와 Oracle OCI Client와 별반 차이가 나지 않게 성능이 개선됨

- 즉 일반적으로 statement cache기능을 사용하는 것을 권장하며 특히 Weblogic드라이버의 경우는 강력히 추천함

 

7) Query 속도 비교

- 25만건의 데이터를 대상으로 unique key를 이용해 단순한 query문을 연속해서 수행해 보았음

- 테스트 결과는 다음과 같음

 

TOTAL ELAPSED TIME

APP TIME

DB CPU

DB WAIT

oci

183.297

12.187

42.24

128.87

thin

191.86

15.2

46.74

129.92

weblogic

185.047

12.547

44.73

127.77

 

 

- 다음은 일량 기준의 테스트 결과임

 

Data from client(MB)

Data to client(MB)

execute count

session logical reads

roundtrips to/from client

USED MEMORY (MB)

oci

5.95

32.18

250010

750020

250006

1.02

thin

16.2

28.12

250009

750018

250005

1.33

weblogic

9.29

18.82

250010

750021

250015

0.84

 

- 테스트의 결과로 보면 Oracle OCI Client 가 가장 좋은 성능을 나타내는 것을 알 수 있고 그 다음으로는 Weblogic thin Client이 그리고 Oracle JDBC thin Client이 가장 좋지 않은 성능을 나타내고 있는 것을 알 수 있음

- 성능의 차이가 나는 부분은 Application, DB 수행, DB 대기에서 전반적으로 나타나고 있으며 특히 SQL을 통해 클라이언트에서 서버로 전송된 데이터양이 차이가 나고 있으며 수행 시간과의 관계가 있음을 알 수 있음.

- 결국 이 테스트의 결과는 얼마나 해당 driver가 최적화되어 있는 지를 간접적으로 증명하는 것으로 생각됨

- 참고로 같은 테이블을 업데이트 하는 경우의 테스트 결과를 첨부함

 

TOTAL ELAPSED TIME

APP TIME

DB CPU

DB WAIT

USED MEMORY(MB)

Data from client(MB)

oci

185.312

16.502

39.95

128.86

1.05

5.95

thin

190.937

19.157

41.46

130.32

1.01

12.15

weblogic

187.391

18.191

40.34

128.86

1.23

9.05

- update의 경우도 OCI, WebLogic, Thin Client의 순서로 나타났고 Thin client의 경우 DB CPU, DB WAIT, APP TIME에서 전반적으로 수행시간이 다른 것에 비해 약간씩 차이가 남.

- 이도 또한 클라이언트에서 서버로 전송된 데이터의 차이가 전체 수행시간의 차이를 만들어 내는 것으로 판단할 수 있음

- Application의 메모리도 관계가 있어 보이긴 하지만 update테스트의 경우에서는 수행시간의 추이와 맞지 않음을 알 수 있음.

- 그러나 전반적으로 최적화된 정도가 전체 성능을 좌우하는 것을 부인할 수는 없음

 

'기술이야기' 카테고리의 다른 글

Connection Cache  (1) 2009.05.26
Oracle JDBC Driver  (0) 2009.05.26
Statement Cache  (0) 2009.05.26
Oracle Update Batching  (0) 2009.05.26
댓글
댓글쓰기 폼