1. 개요

성능이나 장애에 영향을 주는 WebLogic DB 연결 관련 설정이다.


2. 설정

2-1. Seconds to Trust an Idle Pool Connection

The number of seconds within the use of a pooled connection that WebLogic Server trusts that the connection is still viable and will skip connection testing.

If an application requests a connection within the time specified since the connection was tested or successfully used and returned to the connection pool, WebLogic Server skips the connection test before delivering it to an application (if TestConnectionsOnReserve is enabled).

WebLogic Server also skips the automatic refresh connection test if the connection was successfully used and returned to the connection pool within the time specified (if TestFrequencySeconds is specified).

This attribute is a tuning feature that can improve application performance by minimizing the delay caused by database connection testing, especially during heavy traffic. However, it can reduce the effectiveness of connection testing, especially if the value is set too high. The appropriate value depends on your environment and the likelihood that a connection will become defunct.

2-2. Test Frequency

특히 WAS와 DB 사이에 방화벽이 있을 때 주로 사용한다. (그 이유는 방화벽 Timeout에 의하여 DB Connection이 끊어질 수 있음)

The number of seconds between database connection tests. After every TestFrequencySeconds interval, unused database connections are tested using TestTableName. Connections that do not pass the test will be closed and reopened to re-establish a valid physical database connection. If the test fails again, the connection is closed.

If TestTableName is not set, the test will not be performed.

If set to 0 (the default), connections are not tested.

MBean: weblogic.management.configuration.JDBCConnectionPoolMBean

Attribute: TestFrequencySeconds

2-3. Connection Creation Retry Frequency

The number of seconds between attempts to create database connections when the connection pool is created. If you do not set this value, connection pool creation fails if the database is unavailable. If set and if the database is unavailable when the connection pool is created, WebLogic Server will attempt to create connections in the pool again after the number of seconds you specify, and will continue to attempt to create the connections until it succeeds. When set to 0 (the default), this feature is disabled.

MBean: weblogic.management.configuration.JDBCConnectionPoolMBean

Attribute: ConnectionCreationRetryFrequencySeconds

2-4. oracle.net.CONNECT_TIMEOUT

2-5. Statement Cache Size

The Statement Cache Size attribute determines the total number of prepared and callable statements to cache for each connection in each instance of the data source. By caching statements, you can increase your system performance. However, you must consider how your DBMS handles open prepared and callable statements. In many cases, the DBMS will maintain a cursor for each open statement. This applies to prepared and callable statements in the statement cache. If you cache too many statements, you may exceed the limit of open cursors on your database server.

For example, if you have a data source with 10 connections deployed on 2 servers, if you set the Statement Cache Size to 10 (the default), you may open 200 (10 x 2 x 10) cursors on your database server for the cached statements.

내용을 잘 보면 each connection 당 캐시되는 수이다. WebLogic Global의 캐시 제한 숫자가 아니다.

또 주의할 점이 있는데,

  • T4CPreparedStatement의 기본 ResultSet를 베이스로 한 버퍼 크기는 <컬럼 총합 X PreparedStatement의 기본 패치 크기> 이다.
  • 만약 총 컬럼 사이즈 1000바이트에 패치 사이즈 50이라고 하면 이 값은 50,000바이트, 약 50K 가량이 된다.
  • 그래서 각 Connection당 총 100개의 PreparedStatement가 캐싱되어 있다고 하면, 각 Connection 당 약 5,000K, 즉 5MB 가량 점유하고 있는 셈이다.
  • 이것은 각 Connection 당이므로 Connection이 30개 있다고 하면 30 X 5MB = 총 150MB 가량이 된다.

이와 유사하게 JEUS에도 설정이 있다.

Stmt Caching Size

JDBC 드라이버는 애플리케이션에서 PreparedStatement 를 요청할 때마다 파라미터로 넘어온 SQL 문장을 파싱하게 된다. 이 파싱 작업이 성능에 영향을 줄 수 있기 때문에 이를 피하기 위해서 JEUS 내부적으로 PreparedStatement 를 캐시하는 기능을 제공한다. 이 설정은 캐싱할 PreparedStatement 의 개수를 지정한다.

그런데 간혹 이 설정이 -1로 되어 있는 경우가 있다. 이는 캐싱 대상 PreparedStatement의 수가 무한대라는 것이다. 힙 메모리를 점유하여 OOM을 유발할 수 있으므로 반드시 적당한 수로 제한해야 한다.


3. 유형에 따른 접속 방식

3-1. non-RAC & non-XA

XA를 사용하지 않는 Multi Data Sources

 <url> jdbc : oracle : thin : @ lcqsol24 : 1521 : SNRAC1 </ url> 
 <driver-name> oracle.jdbc.OracleDriver </ driver-name>

3-2. non-RAC & XA

XA를 사용하는 Multi Data Source

<url> jdbc : oracle : thin : @ lcqsol24 : 1521 : SNRAC1 </ url> 
<driver-name> oracle.jdbc.xa.client.OracleXADataSource </ driver-name>

3-3. RAC & non-XA

XA를 사용하지 않는 Service 방식

driver-name="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service_1)(INSTANCE_NAME=DB_02)))"

3-4. RAC & XA

XA를 사용하는 Service 방식

driver-name="oracle.jdbc.xa.client.OracleXADataSource"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service1)(INSTANCE_NAME=DBase1)))"

3-5. RAC + XA 주의점

Oracle RAC는 XA 내의 모든 데이터베이스 작업을 동일한 Oracle 인스턴스로 라우팅해야한다. 따라서 로드 밸런싱 옵션은 OFF해야 한다.


4. CTF vs TAF

WebLogic에서 TAF 사용 시 이슈가 있다. 다음은 Oracle 홈페이지에서 발췌한 내용임.

Although Oracle RAC offers JDBC connect-time failover features, for most configurations, Oracle recommends using WebLogic JDBC multi data sources to handle failover instead. While connect-time failover does not provide the ability to pre-create connections to alternate RAC nodes, multi data sources have multiple connections available at all times to handle failover. For more information see Using Multi Data Sources with Oracle RAC.
Transparent Application Failover (TAF) is not supported for any WLS data source. TAF, as delivered via JDBC is currently not transparent. It is documented to affect some ongoing query results and PreparedStatements in unpredictable and unrecoverable ways. TAF JDBC requires specific recovery code at the application level and affects the integrity of statements that WebLogic might be caching.

5. GridLink Data Sources

그런데 GridLink라는 데이터 소스가 등장했다. 아마 WebLogic 12c 부터 나온 것 같은데, 이제까지 알아본 바에 의하면,

  • RAC의 상태를 동적으로 감지하여 동작
  • XA, non-XA 모두 로드 밸런싱 지원
  • 예정된 DB 종료의 경우, 진행 중인 트랜잭션은 DB 연결이 종료되기 전에 처리되며, 이후 새로운 요청은 Active DB에 할당됨
  • 예정되지 않은 DB 종료의 경우, 진행 중인 트랜잭션은 rollback 되고, 이후 새로운 요청은 Active DB에 할당됨

중요한 것은 WebLogic 문서 상에 CTF 방식이 Deprecated 되었다고 나온 것이다. (https://docs.oracle.com/cd/E24329_01/web.1211/e24367/connecttime.htm#JDBCA491)


6. WEB-WAS Plug-in 설정

사실 이 설정은 DB 연결 설정은 아니지만 고려해야 할 내용이기에 추가한다.

6-1. Idempotent

WebLogic Plug-in이 제공하는 설정으로 default는 ON으로 되어 있다. 이 설정은 WLIOTimeSecs 내에 서버가 응답하지 않으면 (READ_ERROR_FROM_SERVER) Failover 해서 처리하겠다는 것이다.

그런데 이 설정을 ON으로 하면 데이터 혹은 서비스가 이중으로 처리될 수 있으므로 설정에 주의해야 한다. 개인적으로는 OFF를 선호한다.