이것저것 정리하는 블로그

 Oracle DBMS를 사용하면서 수 많은 개발자들이 한번쯤은 접하게되는 문제가 "지금 운영중인 DB의 캐릭터셋 설정때문에 한자, 혹은 특정 한글 문자의 입력이 안되는게 당연합니다. 지금 캐릭터셋을 바꾸면 Data가 깨질수도 있어요."라는 DBA의 답변...이다.
 이런말 하기는 참 싫지만 내가 설치한 DB도 아니고... 새로 구축하는 DB면 이렇게 설치 안 하겠는데... 암튼...
(사실 이렇게 말해놓고는 지난번에 설치한 DB는 이 회사 왕고참 과장님의 의견(기존에 사용하던 DB와 캐릭터셋이 같아야 한다는...)에 따라서 KSC5601로 설치했다. 아~ 소신대로 살기 참 힘들죠~잉~)

OTN에 NLS관련 내용을 정리한 문서가 있어서 소개합니다. 언젠간 저도 이런 곳에 문서를 올릴 수 있는 능력자가 될 수 있기를...

보러가기
오라클과 NLS의 찰떡궁합 들여다보기(1)
오라클과 NLS의 찰떡궁합 들여다보기(2)

Comment +0

 OTN 홈페이지에 [고성능 Oracle JDBC 프로그래밍]이라는 문서가 올라왔네요.
원문보러가기 : 고성능 Oracle JDBC 프로그래밍

고성능 Oracle JDBC 프로그래밍

연결 및 명령문 풀링 기능을 이용하여 Oracle 기반의 JDBC 프로그램 성능을 개선하는 방법을 학습합니다.

By Yuli Vasiliev

2009년 4월 게시

연결 풀링 및 명령문 풀링과 같은 풀링 기능을 사용하면 데이터베이스 집약적인 애플리케이션의 성능을 크게 개선할 수 있습니다. 풀링 기능을 사용하지 않을 경우, 처음부터 객체를 새로 만들어야 하므로 시간과 리소스가 많이 소모되지만 풀링을 사용하면 객체를 다시 사용할 수 있기 때문입니다.

애플리케이션에서 사용한 물리적 데이터베이스 연결을 나타내는 데이터베이스 연결 객체를 다시 사용할 경우, 성능을 크게 개선시킬 수 있습니다. 단, 해당 애플리케이션은 동일한 매개 변수를 사용하여 연결을 수시로 재설정하면서 데이터베이스와 끊임없이 상호 작용해야 합니다. 반면, 애플리케이션이 기본 데이터베이스에 연결하는 경우가 거의 없다면 연결 풀을 사용하는 이점이 별로 없을 것입니다. 그러나 실제로는 허용되는 최대/최소 연결 수에 대한 한도 설정 같은 풀 설정이 특정 애플리케이션에 맞게 최적화되어 있다면 많은 데이터베이스 집약적인 애플리케이션이 연결 풀을 사용함으로써 이점을 누릴 수 있습니다.

연결 풀처럼 명령문 풀도 애플리케이션 성능을 개선할 수 있는 방법을 제공합니다. 프로그램을 실행하는 중에 여러 번 실행되는 명령문을 풀링함으로써 추가적인 성능 개선을 얻을 수 있습니다. 그러나 명령문 풀링이 성능 문제를 해결할 수 있는 특효약은 아니라는 점을 기억하십시오. 만약 프로그램에서 명령문이 실행되는 횟수를 구분하지 않고 모든 단일 명령문을 캐시 한다면 성능 개선을 이루지 못할 수 있습니다. 프로그램 실행 중에 한 번만 실행되는 명령문을 캐시할 경우, 해당 명령문을 캐시에 넣고 보관하는 작업과 관련된 오버헤드로 인해 실제로는 성능이 저하될 수 있습니다.

이 문서에서는 Oracle JDBC 씬 드라이버를 통해 Oracle Database와 상호 작용하는 데이터 집약적인 JDBC(Java DataBase Connectivity) 프로그램의 성능을 개선하기 위해 연결 및 명령문의 풀링을 이용하는 방법을 설명합니다. 특히 JDBC 연결을 캐시하기 위해 모든 기능을 갖춘 연결 풀 구현을 제공하는 JDBC용 Oracle Universal Connection Pool(UCP)을 살펴보겠습니다. 마지막으로 Oracle의 JDBC 드라이버뿐 아니라 명령문 인터페이스에 추가되고 JDK(Java Development Kit) 1.6 이상 버전을 지원하는 Oracle JDBC 드라이버에서 사용할 수 있는 새로운 JDBC 4.0 메소드에 관련된 기능을 사용함으로써 명령문 풀링에서 이점을 얻을 수 있는 방법을 설명하겠습니다.


Comment +0

 OTN에 올라온 Oracle RAC 구축 관련 문서입니다. Oracle VM과 Oracle Enterprise Linux 환경에 구축하는 내용을 담고 있으며, 개인이나 회사에서 개발용, 테스트 혹은 교육용으로만 사용할 것을 권장하고 있네요.
세개의 웹 페이지로 나뉘어져있으며, 각 페이지에는 인쇄용 화면을 볼 수 있는 링크가 있습니다.

소개

일반적인 Oracle RAC(Real Application Cluster) 구현은 하나 또는 여러 노드의 장애를 신속하게 복구하는 아키텍처입니다. 그러나 일반적인 시나리오에서 Oracle RAC의 모든 노드는 한 곳의 데이터 센터에 있으므로 치명적인 데이터 센터 장애로 이어지기 쉽습니다. 이 시나리오에서 재난 복구를 위한 솔루션은 로컬 데이터 센터와 일부 백업 데이터 센터 간에 Oracle DataGuard를 설치하여 대기 시스템(일반적으로 하나의 Oracle Database 또는 다른 RAC 클러스터)을 실행하는 것입니다.

DataGuard는 이 역할을 물론 잘 수행하지만 전체 대기 시스템과 어레이를 패시브 노드로 전환하므로 트랜잭션에 전산 능력을 사용할 수 없게 되며 이로 인해 솔루션 비용이 매우 높아집니다. (대기 Oracle DataGuard 시스템은 읽기 전용 쿼리를 수행하기 위해 열 수 있고 Active DataGuard in Oracle Database 11g를 사용할 경우 항상 읽기 전용 모드로 실행할 수도 있지만, 이 구성의 경우 애플리케이션이 일부 노드의 읽기 전용 특성을 알고 있어야 합니다.)

다행히도 부분적인 재난 복구를 위한 다른 솔루션이 있으며 그것이 바로 확장 RAC입니다. 이 아키텍처에서 일부 RAC 노드는 "알파 사이트"에서 작동하며 나머지 노드는 "베타 사이트"에서 작동합니다. 두 사이트의 노드는 액티브 모드이므로 모든 전산 리소스를 충분히 사용합니다. 그림 1에서 볼 수 있는 것처럼 각 사이트에는 전용 SAN(Storage Area Network)이 있고, 양쪽 데이터 센터(dcA와 dcB)에 있는 시스템은 동일한 RAC의 구성원이므로 데이터를 신속하게 상호 교환할 수 있고 다른 사이트의 스토리지에 액세스할 수 있습니다. 즉, dcA에 있는 RAC1 노드는 dcB에 있는 SAN 어레이에 데이터를 쓰고 dcB에 있는 RAC2 노드와도 통신합니다.



원문 : Oracle VM 및 Oracle Enterprise Linux에 Oracle 확장 RAC 클러스터 직접 구축하기



Comment +0