JDBC 문제 조사
문제 설명
JDBC 커넥션 풀을 구성하거나 권장되지 않는 프로그래밍 기법을 사용하면 JDBC 풀 커넥션, 관련 데이터베이스 또는 WebLogic Server 인스턴스와 관련된 많은 문제가 발생할 수 있습니다. 또한 기본 데이터베이스와 네트워크 구성 및 아키텍처도 JDBC 커넥션과 관련된 문제를 초래할 수 있습니다.
문제 해결
이 패턴은 이러한 문제를 해결할 수 있는 유용한 정보와 JDBC 문제를 자세히 조사하는 방법을 제공합니다. 다음 항목을 모두 수행해야 하는 것은 아닙니다. 어떤 경우에는 다음 중 일부만 수행하여도 해결할 수 있습니다.
JDBC 커넥션 풀 문제
JDBC 커넥션 풀 구성 및 조정은 응용 프로그램 서버와 응용 프로그램 자체의 성능과 안정성을 보장하기 위한 아주 중요한 관리 작업입니다. 풀을 잘못 구성하면 다음과 같은 다양한 문제가 발생할 수 있습니다.
JDBCDataSource.getConnection() 실행 중 ResourceException(weblogic.common.ResourceException: No resources available)이 발생합니다.
RDBMS 또는 네트워크의 취약한 성능으로 인해 기본 데이터베이스에 대한 커넥션 요청 시 WebLogic Server의 시작 시간이 아주 길어집니다.
JDBC 드라이버 구성 문제 때문에 JDBC 풀 커넥션을 생성하는 동안 오류나 예외가 발생합니다.
데이터베이스가 다운된 후 연결 새로 고침/다시 연결 문제가 발생합니다.
데이터베이스 문제
JDBC 풀 커넥션은 데이터베이스에 연결된 세션을 나타냅니다. JDBC 풀 구성은 데이터베이스 자체에 문제를 일으킬 수 있습니다. 또한 WebLogic Server와 데이터베이스 간 네트워크 연결은 다음과 같은 문제를 일으킬 수 있습니다.
Oracle 데이터베이스에 열린 커서가 너무 많습니다.
방화벽이 데이터베이스와 WebLogic Server 간 유휴 커넥션을 닫습니다.
getVendorConnection()이 기본 커넥션을 수신하는 데 사용되는 경우 RemoveInfectedConnectionsEnabled 속성 설정을 선택해야 합니다.
WebLogic Server 문제
JDBC 풀은 WebLogic Server 리소스를 사용하여 할당된 작업을 수행합니다. 따라서 JDBC 문제는 WebLogic Server에서 다음과 같은 문제를 일으킬 수 있습니다.
WebLogic Server가 native JDBC 드라이브 라이브러리로 인해 크래시됩니다.
WebLogic Server나 응용 프로그램이 JDBC 드라이버 메쏘드 또는 function에서 Hang(정지)됩니다.
JDBC Object의 메모리 leak 때문에 OutOfMemoryError가 발생하거나 프로세스 크기가 커집니다.
일반 항목
이 절에서는 일반 JDBC 커넥션 풀 항목에 대한 조정 및 문제 해결 정보를 제공합니다.
JDBC 문제 해결, 디버깅 또는 추적
WebLogic Server 멀티 풀 페일오버(failover) 또는 로드 밸런싱 이해
운영 환경에 대한 JDBC 커넥션 풀을 조정하는 방법
WebLogic Server 및 Oracle RAC/TAF
Oracle ORA-01591 예외
JDBC 커넥션 풀 문제
JDBCDataSource.getConnection() 실행 중 ResourceException(weblogic.common.ResourceException: No resources available)이 발생합니다.
DataSource를 통해 JDBC 커넥션 풀에 대한 getConnection() 요청이 해당 풀에 커넥션이 없거나 커넥션 요청을 처리하는 데 사용할 수 있는 스레드가 없기 때문에 충족될 수 없는 경우 ResourceException이 발생합니다. 리소스가 없는 경우 다음 중 하나가 원인일 수 있습니다.
응용 프로그램에서 커넥션 leak이 발생했습니다.
JDBC 풀에서 사용된 커넥션은 응용 프로그램 코드에서 사용한 후 닫아야 합니다. close()가 호출되지 않으면 커넥션이 해제되지 않고 재사용할 수 없습니다.
ORA-00020 - maximum number of processes (600) exceeded 오류 메시지가 나타나면 Oracle JDBC 커넥션 풀에서 커넥션 leak이 발생했다는 신호일 수 있습니다.
이 주제는 준비되는대로 별도의 패턴으로 처리하여 더 자세히 설명하겠습니다.
WebLogic Server는 커넥션 leak 감지 기능을 제공합니다. 응용 프로그램이 모든 JDBC 풀 커넥션을 제대로 닫지 않는 것 같으면 이 기능을 활성화하여 해당 상황을 분석할 수 있습니다. 이 속성은 커넥션 풀 단위로 설정될 수 있습니다. ConnLeakProfilingEnabled 속성에 대한 설명서는
http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#ConnLeakProfilingEnabled에서 다운로드할 수 있습니다. 이 속성은 콘솔을 통해 설정할 수 있습니다. 관련 정보는 http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_config_connections.html#1104722를 참조하십시오.
너무 적은 수의 스레드 또는 너무 적은 수의 커넥션(MaxCapacity)이 구성되어 응용 프로그램에서 요구하는 동시 활성 데이터베이스 커넥션 수를 충족시킬 수 없습니다.
이 경우 일반적인 규칙은 JDBC 풀의 데이터베이스 커넥션 수(MaxCapacity)를 실행 스레드 수와 같게 구성하는 것입니다. 이 값은 동시에 활성화될 수 있는, 즉 트랜잭션에 참가할 수 있는 데이터베이스 커넥션 수를 제한하므로 용량 계획 시 이러한 점을 고려해야 합니다.
최다 커넥션은 응용 프로그램이 풀에 사용 가능한 커넥션이 없음을 의미하는 ResourceException을 받는 동안에도 발생합니다.
프로그램을 분석한 결과 응용 프로그램 코드에서 실제로 사용된 것보다 더 많은 커넥션이 예약되었고 커넥션 leak을 배제한 경우 RefreshMinutes 간격 속성이 너무 빈번하게 설정되었을 가능성이 높습니다. 새로 고침 기능을 해제하려면 다음과 같이 합니다.
WLS 8.1 이상인 경우 TestFrequencySeconds를 0으로 설정합니다.
WLS 7.0인 경우 RefreshMinutes를 0으로 설정합니다.
이전 버전의 경우 RefreshMinutes를 99999999(최대값: 35791394)로 설정합니다. 0으로 설정하면 디폴트값 5분으로 환원됩니다.
새로 고침 기능은 풀에서 현재 사용되지 않는 모든 커넥션을 테스트 테이블을 사용하여 테스트한 다음 필요한 경우(테스트가 실패한 경우) 연결을 새로 고치기 위한 것입니다. 이 기능을 설정하려면 테스트 테이블을 정의하고 JDBCConnectionPool에서 RefreshMinutes 속성을 정의합니다.
새로 고침은 클라이언트 응용 프로그램 코드에 대해 비동기적으로 실행되고 테스트를 위해 현재 사용되지 않은 모든 풀 커넥션을 일시적으로 유지합니다. 전체 테스트 시간 동안 모든 커넥션을 유지합니다. 이 기간 동안 새로운 응용 프로그램의 커넥션 요청이 들어오면 다음과 같은 상황이 발생합니다.
InitialCapacity가 MaxCapacity보다 작고 현재 열려있는 MaxCapacity 커넥션보다 작은 경우 들어오는 모든 커넥션 요청은 풀에서 허용되는 최대 커넥션에 도달할 때까지 CapacityIncrement의 새 커넥션을 엽니다. 그 결과 실제로 동시에 사용되는 것보다 많은 커넥션이 열릴 수 있기 때문에 최다 커넥션이 발생할 수 있습니다.
최대 커넥션 수가 이미 열려 있으면 ResourceException이 발생합니다.
JDBC 풀에 대해 실제로 새로 고침 기능이 필요한지 여부를 신중하게 고려해야 합니다. WebLogic Server와 데이터베이스 간에 실제로 유휴 소켓 커넥션을 닫는 방화벽이 있는 경우 새로 고침 기능은 아주 유용합니다. 자세한 내용은 방화벽이 유휴 커넥션을 닫습니다를 참조하십시오.
필요한 경우 다음과 같이 다른 커넥션 테스트 및 새로 고침 옵션을 사용할 수 있습니다.
TestConnectionsOnReserve 속성을 true로 설정합니다. 이렇게 하면 풀에서 요청되는 모든 커넥션은 응용 프로그램 코드로 전송되기 전에 테스트됩니다. 테스트가 실패할 경우 자동으로 다시 열립니다.
데이터베이스가 일시적으로 사용 가능하지 않거나 다운된 경우 weblogic.Admin RESET_POOL을 사용하여 커넥션 풀을 완전히 새로 고칠 수 있습니다. 새로 고침 기능은 사용되지 않은 커넥션만 새로 고치지만 이렇게 하면 모든 커넥션이 새로 고쳐집니다.
RDBMS 또는 네트워크의 취약한 성능으로 인해 기본 데이터베이스에 대한 커넥션 요청 시 WebLogic Server의 시작 시간이 아주 길어집니다.
WebLogic Server 시작 시 JDBCConnectionPool의 InitialCapacity 속성은 즉시 생성되는 커넥션의 수량을 정의합니다. 데이터베이스에 대한 기본 커넥션을 생성하고 초기화하는 데 오랜 시간이 걸리면 WebLogic Server 인스턴스를 시작하는 시간도 아주 오래 걸립니다.
일반적으로 데이터베이스에 대한 커넥션 요청이 오랜 시간이 걸리는 경우 WebLogic Server를 시작하는 시간이 이처럼 오래 걸리지 않도록 하려면 InitialCapacity를 0으로 설정하면 됩니다. 이렇게 하면 WebLogic Server 시작 시 커넥션 없이 풀이 생성됩니다. 첫 번째 커넥션 요청 시 모든 커넥션이 생성되도록 하려면 CapacityIncrement를 풀에서 사용 가능한 총 커넥션 수로 설정합니다. 첫 번째 요청은 아주 오래 걸리지만 그 후에는 커넥션 풀이 완전히 실행 가능한 상태가 됩니다.
WLS 8.1 SP2 이상에서 제공되는 Oracle type-4 드라이버와 같은 일부 JDBC 드라이버는 커넥션 요청이 기다리는 최대 시간을 제한하는 속성을 갖고 있습니다. 이러한 드라이버의 경우 config.xml에서 JDBCConnectionPool에 대한 Properties 특성에 LoginTimeout 속성을 지정하십시오. 이 값은 WebLogic Server에 의해 JDBC 드라이버로 전달됩니다. 자세한 내용은 지원 솔루션 S-06615를 참조하십시오.
JDBC 드라이버 구성 문제 때문에 JDBC 풀 커넥션을 생성하는 동안 오류나 예외가 발생합니다.
위에서 언급했듯이 WebLogic Server는 시작 시 InitialCapacity 수 만큼의 커넥션을 생성하려고 시도합니다. JDBC 풀이 제대로 구성되지 않거나 WebLogic Server를 시작하는 동안 데이터베이스를 사용할 수 없으면 커넥션이 초기화되지 못합니다. 따라서 WLS 8.1 이전의 버전에서는 JDBC 커넥션 풀이 생성되지 않고 차후에 사용할 수 없었습니다. 또한 풀을 새로 고치거나 삭제하거나 다시 생성할 수도 없었습니다. 이 문제를 해결하려면 시작하는 동안에는 어떤 커넥션도 열지 않는 JDBC 풀을 구성해야 합니다(InitialCapacity="0"). 데이터베이스를 다시 사용할 수 있게 되면 열린 커넥션이 없는 커넥션 풀이 생성되고 해당 풀에 대한 모든 커넥션 요청은 CapacityIncrement 커넥션을 엽니다. 그렇지 않은 경우 데이터베이스가 계속 다운되면 오류 메시지가 발생합니다.
이 기능은 WLS 8.1에서 변경되었습니다. JDBC 풀을 만드는 동안 문제가 있으면 초기 커넥션 수가 0인 JDBC 풀이 생성됩니다. WebLogic Server가 실행 중인 동안 구성이 변경될 수 있습니다. 풀이 정확히 구성되거나 데이터베이스가 백업된 후 해당 풀에 커넥션이 생성될 수 있고 응용 프로그램에서 해당 풀을 사용할 수 있습니다.
타사 드라이버를 포함하여 여러 드라이버에 대한 JDBC 커넥션 풀을 구성하는 방법은 http://e-docs.bea.com/wls/docs81/jdrivers.html을 참조하십시오.
JDBC 풀을 잘못 구성하여 발생하는 일반적인 오류 메시지는 다음과 같습니다.
다음과 유사한 오류 메시지가 나타나면 지정한 사용자/암호를 수정하십시오.
<05.11.2003 11.38 Uhr CET> <Error> <JDBC> <BEA-001150> <Connection Pool "myPool" deployment failed with the following error: 0:
Could not connect to 'oracle.jdbc.driver.OracleDriver'.
The returned message is: ORA-01017: invalid username/password; logon denied
로그인 또는 암호가 잘못되었을 수 있습니다.
구성에 올바르지 않은 항목이 있거나 데이터베이스를 사용할 수 없을 가능성도 있습니다.
다음과 유사한 오류 메시지가 나타나면 데이터베이스 이름을 수정하십시오.
<06.11.2003 14.21 Uhr CET> <Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "myPool": E/A-Exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153092352)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=125
05)(EMFI=4))))>
<06.11.2003 14.21 Uhr CET> <Error> <JDBC> <BEA-001150> <Connection Pool "myPool" deployment failed with the following error:
0:Could not create pool connection. The DBMS driver exception was: E/A-Exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153092352)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=12505)(EMFI=4)))).>
다음과 유사한 오류 메시지가 나타나면 tns 항목이나 PATH 또는 LD_LIBRARY_PATH 같은 환경 설정을 확인하십시오. Windows의 경우 PATH는 클라이언트 및 OCI 라이브러리를 가리켜야 하고, Unix 환경의 경우 LD_LIBRARY_PATH는 클라이언트 설치 프로그램이 클라이언트와 oci 라이브러리를 복사한 디렉터리를 가리켜야 합니다.
####<Apr 17, 2003 1:58:44 PM CEST> <Error> <JDBC> <mydomain> <myserver> <main> <kernel identity> <> <001060> <Cannot startup connection pool "myPool" weblogic.common.ResourceException:
weblogic.common.ResourceException:
Could not create pool connection. The DBMS driver exception was:
java.sql.SQLException: Io exception: The Network Adapter could not establish the connection
tnsnames.ora 파일 또는 ORACLE_HOME이 제대로 설정되지 않으면 다음과 같은 Oracle 오류가 발생합니다.
ORA-12154: TNS could not resolve service name
ORACLE_HOME 환경 변수가 해당 디렉터리를 가리키고 tnsnames.ora 파일이 해당 디렉터리에 저장되어 있는지 확인하십시오. sql-plus를 통해 이 데이터베이스에 대한 연결이 성공적인지 확인하십시오. ORA-12154 및 관련 Oracle SQL 오류에 대한 자세한 내용은 지원 솔루션 S-08804를 참조하십시오.
관련된 오류 메시지는 ORA-24327로 원인은 대부분 구성 문제입니다.
LOGIN ERROR CODE: 24327
<Error> <JDBC Connection Pool> Cannot startup connection pool "xxxPool" weblogic.common.ResourceException:
Could not create pool connection. The DBMS driver exception was: java.sql.SQLException: ORA-24327: need explicit attach before authenticating a user .
ORA-24327 및 관련 Oracle SQL 오류에 대한 자세한 내용은 지원 솔루션 S-08804를 참조하십시오.
로케일을 잘못 설정해도 다음과 유사한 오류 메시지가 발생할 수 있습니다.
weblogic.management.DeploymentException: Error creating connection pool myConnectionPool:
0:Unable to load locale categories
WebLogic Server를 시작하기 전에 올바른 로케일 환경을 설정했는지 확인하십시오. 동일한 환경에서 데이터베이스 클라이언트를 시작하여 로케일이 제대로 작동하는지 확인하십시오.
데이터베이스가 다운된 후 연결 새로 고침/다시 연결 문제가 발생합니다.
데이터베이스가 주기적으로 다운되는 경우 TestConnectionsOnReserve 속성이 true로 설정되어 있고 커넥션 테스트 쿼리가 실패하면 커넥션이 재설정되거나 새로 고쳐집니다. WebLogic Server 로그 파일에서 다음과 유사한 관련 메시지를 찾을 수 있습니다.
ORA-03113 end-of-file on communication channel 및/또는 ORA-01012 not logged on
<Jan 31, 2002 2:20:17 PM PST> <Info> <JDBC Pool oraclePool> <null> <This connection will now be refreshed.>
<Jan 31, 2002 2:20:18 PM PST> <Info> <JDBC> <001067> <Connection for pool "oraclePool" refreshed.>
<Jan 31, 2002 2:20:18 PM PST> <Info> <JDBC Pool oraclePool> <null> <A connection from pool oraclePool was tested during reserve with a select count(*) from dual and failed:>
<Jan 31, 2002 2:20:18 PM PST> <Info> <JDBC Pool oraclePool> <null>
<java.sql.SQL
Exception: ORA-03113: end-of-file on communication channel
at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:240)
at weblogic.jdbc.oci.Statement.execute(Statement.java:534)
at weblogic.jdbc.common.internal.ConnectionEnv.test(ConnectionEnv.java:961)
at weblogic.jdbc.common.internal.ResourceAllocator.reserve(ResourceAllocator.java:651)
at weblogic.jdbc.common.internal.ResourceAllocator.reserveUnused(ResourceAllocator.java:575)
at weblogic.jdbc.common.internal.ResourceAllocator.trigger(ResourceAllocator.java:1296)
at weblogic.time.common.internal.ScheduledTrigger$1.run(ScheduledTrigger.java:171)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:807)
at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:168)
at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:158)
at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:38)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:156)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:137)
이 메시지는 정보용이므로 그 후에 커넥션이 성공적으로 생성될 수 있으면 무시해도 됩니다.
데이터베이스 문제
Oracle 데이터베이스에 열린 커서가 너무 많습니다.
Oracle 데이터베이스에서 허용된 열린 커서 수로 지정된 값을 초과할 경우 다음 오류 메시지가 발생합니다.
java.sql.SQLException: ORA-01000: maximum open cursors exceeded
이 메시지는 다음 원인으로 인해 발생할 수 있습니다.
Prepared Statement 캐시와 관련된 JDBC 풀 구성을 확인하십시오. 모든 Prepared Statement는 Oracle 데이터베이스에서 하나의 열린 커서를 사용합니다. Statement 캐시는 Prepared Statement를 커넥션별로 보유합니다. 따라서 Oracle 데이터베이스는 구성된 모든 풀에 대해 최대
(StatementCacheSize) x(MaxCapacity)개의 열린 커서를 사용합니다. 열린 커서는 다른 Object(예: 저장 프로시저 또는 결과 집합)에 대해서도 사용되므로 열린 커서의 수는 명령문 캐시에 있는 모든 명령문을 보유할 정도로 크게 구성되어야 합니다. OPEN_CURSORS는 세션/커넥션별로 설정됩니다.
명령문 캐시 구성에 대한 자세한 내용은 http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#StatementCacheSize를 참조하십시오.
일부 Oracle 드라이버 버전(thin 또는 oci)에는 XA 드라이버 클래스(oracle.jdbc.xa.client.OracleXADataSource)에 나중에 ORA-01000 오류 메시지를 발생시키는 커서 leak이 있습니다. 데이터베이스 측면에서 DBA_PENDING_TRANSACTION 보기에 올바른 사용 권한이 있는지 확인하십시오.
grant DBA_PENDING_TRANSACTIONS to public
grant DBA_PENDING_NEIGHBORS to public
grant DBA_2PC_PENDING to public
Oracle 버전 9.2.0.5 및 10g에서는 커서 leak이 수정되었습니다. 이 알려진 문제는 Oracle Metalink Case 3151681에 설명되어 있습니다(Oracle Metalink 로그인 필요).
자세한 내용은 ORA-01000: Maximum open cursors exceeded" 조사 패턴을 참조하십시오.
방화벽이 데이터베이스와 WebLogic Server 간 유휴 커넥션을 닫습니다.
데이터베이스와 WebLogic Server 간에 방화벽이 구성되고 이 방화벽이 일정 시간 후 유휴 커넥션을 닫는 경우 JDBC 풀 새로 고침 기능을 사용하여 해당 풀의 커넥션이 방화벽에 의해 닫히지 않도록 설정할 수 있습니다. 이러한 닫힌 커넥션이 사용된 후 발생하는 일반적인 오류 메시지는 다음과 같습니다.
java.sql.SQLException: ORA-03113: end-of-file on communication channel
at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:240)
at weblogic.jdbc.oci.Statement.executeQuery(Statement.java:916)
at ...
소켓 커넥션이 WebLogic Server 측과 데이터베이스 측 모두에서 정상으로 간주되므로 이 오류가 발생합니다. 따라서 양쪽 모두 이 소켓 커넥션에 쓰려고 시도하면 참여하는 쪽에 알림 또는 오류 메시지를 보내지 않고 소켓 커넥션이 방화벽에 의해 닫히기 때문에 실패합니다. 새로 고침 기능을 사용하여 방화벽이 커넥션을 닫을 정도로 오랫동안 커넥션을 유휴 상태로 두지 마십시오.
다음 설정을 통해 새로 고침 기능을 구성할 수 있습니다.
유휴 기간 동안 최소한 한 번 이상 커넥션을 테스트하도록 RefreshMinutes 속성을 설정합니다. 새로 고침 기능을 활성화하려면 TestTableName 속성도 설정해야 합니다. 자세한 내용은 http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#RefreshMinutes를 참조하십시오.
그러나 모든 JMS 서버는 JDBC 저장소가 정의된 경우 JDBC 풀에서 하나의 커넥션을 가져옵니다. 이 커넥션은 풀에 의해 예약된 것으로 간주되므로 새로 고침 기능은 해당 커넥션을 테스트하거나 새로 고치지 않습니다. 일반적인 오류 메시지는 다음과 같습니다.
JMSServer "myJMSServer", store failure while writing message for queue myQueue, java.io.IOException
이러한 상황은 다음 옵션 중 하나를 사용하여 해결할 수 있습니다.
방화벽이 커넥션을 닫지 않도록 유휴 기간 중에 최소한 하나 이상의 형식적인 JMS 메시지를 보냅니다.
방화벽의 커넥션 닫기 기능을 비활성화합니다.
JMS 서버에 대해 JDBC 저장소로 사용할 별도의 JDBC 풀을 정의하고 weblogic.Admin RESET_POOL을 사용하여 유휴 기간 중에도 최소한 한 번 이상 커넥션을 다시 엽니다.
이후의 WebLogic Server 버전(WLS 6.1 SP7, WLS 7.0 SP3 및 WLS 8.1 SP1)에서는 JMS가 유휴 상태인 경우 데이터베이스가 5분마다 ping 테스트를 수행하여 커넥션을 새로 고치고 방화벽이 이러한 커넥션을 닫지 못하도록 함으로써 이 문제를 해결했습니다.
getVendorConnection()이 기본 커넥션을 수신하는 데 사용되는 경우 RemoveInfectedConnectionsEnabled 속성 설정을 선택해야 합니다.
일부 고급 JDBC 명령에서는 커넥션을 인수로 사용해야 합니다. 이렇게 하기 위해 getVendorConnection()을 호출하여 커넥션 풀이 사용하는 커넥션을 가져올 수 있습니다.
그러나 커넥션을 사용하는 응용 프로그램 코드는 후속 문제를 피하기 위해 조심스럽게 구현해야 합니다. JDBC 커넥션 풀은 가능하면 보안 및 가용성을 높이도록 구현되기 때문에 getVendorConnection()을 호출한 모든 커넥션은 응용 프로그램에 의해 사용된 후 자동으로 새로 고쳐집니다(RemoveInfectedConnectionsEnabled="true").
이것은 커넥션 풀의 효과를 잃는 것을 의미하므로(즉, 사용 후 모든 커넥션이 닫혔다 다시 열리므로) 응용 프로그램 코드에서 다시 열어야 하는 커넥션의 특정 항목을 변경하거나 제거할 경우 신중하게 판단하십시오. 이러한 경우에 해당하지 않는 경우에만 RemoveInfectedConnectionsEnabled 속성을 false로 설정하십시오.
이 속성에 대한 내용은
http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#RemoveInfectedConnectionsEnabled를 참조하십시오.
WebLogic Server 문제
native JDBC 드라이버 라이브러리 때문에 WebLogic Server가 크래시됩니다.
type-2 JDBC 드라이버는 native 코드를 사용하므로 이러한 드라이버에서 문제가 발생하면 JVM 및 WebLogic Server가 크래시될 수 있습니다. 서버가 크래시된 경우 바이너리 코어 파일 분석 패턴에서 제공하는 정보를 참조하십시오. 이 정보는 크래시의 원인이 되는 native 라이브러리를 추적하는 데 도움이 되고 문제를 해결하는 데 필요한 유용한 정보를 제공합니다.
WebLogic Server 또는 응용 프로그램은 JDBC 드라이버 메쏘드 또는 function에서 Hang(정지)됩니다.
JDBC 커넥션은 WebLogic Server에서 실행 스레드를 사용하여 해당 작업을 수행합니다. 즉, 데이터베이스에 대한 Hang(정지) 요청은 WebLogic Server에서 하나의 스레드를 차단합니다. JDBC 커넥션 또는 데이터 인프라에 문제가 있으면 WebLogic Server 또는 응용 프로그램에서 Hang(정지)이 발생할 수 있습니다. 이러한 문제의 분석에 대한 자세한 내용은 JDBC로 인한 서버 Hang(정지) 패턴을 참고하십시오. WebLogic Server에서 Hang(정지) 상황을 추적하는 방법은 일반적인 서버 Hang(정지) 패턴을 참조하십시오.
JDBC Object의 메모리 leak이 있으면 OutOfMemoryError가 발생하거나 프로세스 크기가 커집니다.
JDBC 커넥션 풀의 커넥션이나 응용 프로그램 코드에서 사용되며 직접 데이터베이스에 연결되는 JDBC Object는 프로세스의 힙 또는 native 메모리 부분입니다. 이러한 Object가 제대로 닫히지 않고 해제되지 않은 경우 메모리 leak이 발생하고 이로 인해 힙 사용량이 증가하거나 프로세스 크기가 늘어나 JVM 또는 운영 체제가 더 이상 사용 가능한 메모리를 제공할 수 없게 되면 OutOfMemoryError가 발생합니다.
시스템에서 OutOfMemoryErrors가 발생한 경우 JDBC 개체가 문제의 원인으로 의심된다면 OutOfMemory/메모리 Leak 문제 조사 패턴에서 메모리 leak 문제 분석 방법에 대한 내용을 참조하십시오. WebLogic Server 로그 파일이나 관리 콘솔에서 JDBC 풀 모니터링을 통해 커넥션 leak 오류 메시지를 검색한 경우 앞으로 발표될 JDBC 커넥션 Leak 조사 패턴에서 이 문제에 대한 해결 방법을 제공할 것입니다. 링크는 발표되는 대로 제공될 것입니다.
일반 항목
JDBC 디버깅 또는 추적을 통한 JDBC 문제 해결
JDBC 디버깅 및 추적은 현재 진행 중인 작업을 찾아내고 실제로 데이터베이스로 보내지는 SQL 문을 분석하기 위한 중요한 수단으로 종종 사용됩니다. 그러나 JDBC는 여러 계층으로 이루어진 하위 시스템이며 그 중 일부만 WebLogic Server 내에 있습니다. JDBC 드라이버 계층의 디버깅 및 추적은 드라이버에 크게 좌우됩니다. 드라이버에 대한 디버그 및 추적 플래그 관련 정보는 드라이버 공급업체로부터 얻을 수 있습니다.
WebLogic Server 측에서 다음과 같은 여러 가지 JDBC 디버그 플래그를 사용할 수 있습니다.
관리 콘솔을 통해 또는 config.xml에서 직접 Server 태그에 <JDBCLoggingEnabled>를 설정하여 jDriver JDBC 추적을 전환할 수 있습니다. 자세한 내용은 http://e-docs.bea.com/wls/docs81/config_xml/Server.html#JDBCLogFileName을 참조하십시오.
ServerDebugMBean에는 config.xml에서 설정할 수 있는 몇 가지 JDBC 관련 플래그가 있습니다. 새 <ServerDebug> 태그를 디버그할 WebLogic Server 인스턴스의 <Server> 태그에 넣으십시오. 아래의 예를 참조하십시오.
<Server Name="myserver" >
....
<ServerDebug Name="myserver" JDBCConn="true" JDBCSQL="true" JTAJDBC="true" />
</Server>
또한 WebLogic Server 시작 시 시스템 속성으로 이러한 디버그 플래그를 설정할 수도 있습니다.
-Dweblogic.Debug=weblogic.JDBCConn,weblogic.JDBCSQL,weblogic.JTAJDBC
이러한 디버그 플래그 및 추적은 매우 복잡할 수도 있으므로 해당 플래그를 설정할 위치를 아주 신중하게 판단해야 합니다. 디버그 플래그와 추적을 사용하면 많은 출력이 생성되고 시스템 성능에 영향을 줄 수 있으므로 운영 시스템에서는 설정하지 마십시오.
JDBC 디버깅 설정을 허용하지 않거나 충분한 정보를 출력하지 않는 드라이버의 경우 P6Spy 드라이버를 설치하면 JDBC 드라이버와 데이터베이스 사이의 모든 SQL 문을 디버그하는 데 도움이 될 수 있습니다. 이렇게 하면 디버그 정보를 로그 파일에 출력하는 추가 계층이 구현됩니다. 해당 드라이버는 다음 웹 사이트에서 다운로드할 수 있습니다.
http://www.p6spy.com/
설명서와 설치 지침은 http://www.p6spy.com/documentation/index.htm에서 다운로드할 수 있습니다.
WebLogic Server의 멀티 풀 페일오버(failover) 또는 로드 밸런싱 이해
WebLogic Server 멀티 풀은 고가용성 또는 로드 밸런싱 목적으로 사용될 수 있습니다. 이 구성에 따라 멀티 풀 동작이 달라집니다. 멀티 풀 페일오버(failover) 및 로드 밸런싱에 대한 자세한 내용은 JDBC 멀티 풀 문제 조사 패턴을 참조하십시오.
운영 환경에 대한 JDBC 커넥션 풀을 조정하는 방법
운영 시스템에 대한 JDBC 커넥션 풀을 구성하는 것은 안정성과 성능을 보장하기 위해 필수적인 중요한 작업입니다. 다음은 관리자가 처음 시작할 때 도움이 될 수 있는 몇 가지 일반적인 권장 사항입니다.
InitialCapacity를 MaxCapacity로 설정
이렇게 하면 WebLogic Server를 시작할 때 모든 커넥션이 열립니다. 실제 데이터베이스 커넥션을 생성하려면 많은 비용이 들기 때문에 필요한 커넥션은 모두 즉시 열고 계속 열린 상태로 유지해야 합니다.
ShrinkingEnabled를 false로 설정하여 축소 기능 비활성화
위에서 언급했듯이 실제 데이터베이스 커넥션을 생성하려면 비용이 많이 들기 때문에 커넥션을 한 번 설정한 후 WebLogic Server 인스턴스의 전체 수명 동안 열린 상태로 유지해야 합니다.
필요하지 않은 경우 새로 고침 기능 해제 - 자세한 내용은 위의 JDBC 커넥션 풀 문제 및 데이터베이스와 WebLogic Server 사이의 방화벽을 참조하십시오.
TestConnectionsOnReserve를 true로 설정
이렇게 하면 필요한 경우 응용 프로그램으로 커넥션을 보내 다시 열기 전에 테스트할 수 있습니다.
TestConnectionsOnRelease를 false로 설정
커넥션 테스트는 가능하면 피해야 하는 오버헤드이므로 응용 프로그램이 풀로 돌려보내는 커넥션에 대해 커넥션 테스트를 수행하는 것은 불필요한 작업입니다. getConnection 동안 커넥션을 테스트하면 이러한 작업이 필요하지 않습니다.
JDBC 풀의 커넥션 수를 커넥션을 사용하는 execute 스레드의 수와 같게 설정
이렇게 하면 ResourceExceptions를 피할 수 있습니다.
WebLogic Server 및 Oracle RAC/TAF
Oracle RAC/TAF에 대한 JDBC 커넥션 풀을 구성할 경우 몇 가지 세부 사항을 고려해야 합니다. 자세한 내용은 Oracle RAC(Real Application Clusters) 구성 및 테스트 패턴을 참조하십시오. 이 패턴에는 Oracle RAC 설치 및 구성 방법, 몇 가지 일반적인 Oracle RAC/TAF 문제에 대한 정보, 기본 디버깅 팁 및 외부 리소스에 대한 정보가 포함되어 있습니다.
Oracle ORA-01591
분산 트랜잭션에서 사용되는 데이터베이스나 기타 리소스에 문제가 있으면 Oracle 데이터베이스에서 ORA-01591 오류 메시지가 나타날 수 있습니다. 앞으로 발표될 ORA-01591 오류 메시지 조사 패턴에서 이 문제를 분석한 정보를 제공할 것입니다. 링크는 발표되는 대로 제공될 것입니다.
관련 자료
다양한 JDBC 드라이버 및 해당 드라이버 구성에 대한 내용은 http://e-docs.bea.com/wls/docs81/jdrivers.html을 참조하십시오. XA 및 분산 트랜잭션을 사용하는 경우에는 특히 데이터베이스 관련 설정을 확인하십시오.
트랜잭션 관련 문제 해결 방법에 대한 자세한 내용은 트랜잭션 문제 조사 패턴을 참조하십시오.
http://e-docs.bea.com/wls/docs81/jdbc/index.html의 JDBC 프로그래밍 설명서에는 다양한 종류의 JDBC 드라이버 및 해당 래퍼에 대한 정보와 응용 프로그램 코드에서 이들을 사용하는 방법이 설명되어 있습니다. 이 링크에서 성능 조정에 대한 유용한 정보도 찾을 수 있습니다.
사용 가능한 JDBCConnectionPool 속성의 전체 목록을 보려면 http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#252800을 참조하십시오.
|
![[응답]weblogic jdbc 디버그](img/next.gif){kind=small}