「64비트 데이터베이스, 이럴 때만 사용해라」

만약 현 시스템으로 32비트 컴퓨팅의 한계를 전혀 느끼지 못했다면 64비트 환경으로 이전해도 성능에 도움이 안될 것이다.그러나 속도가 최우선 순위인 미션 크리티컬 데이터베이스에서는 32 비트 프로세서를 아무리 추가해도 도움이 안될 수 있다.오라클은 다양한 64비트 대 32비트 관련 부가기능을 제공하며 솔라리스, HP/UX, AIX 등 사유 유닉스를 이용하는 기업들은 64비트 서버에서 32비트 버전 오라클 데이터베이스를 실행시킬 수 있는 옵션도 사용할 수 있다.많은 오라클 튜닝 전문가들은 서버 전체 업그레이드를 권장하는 경우 16비트 PC 대 32비트 PC의 성능에 비유해 설명한다. 일반적으로 더 빠른 CPU 아키텍처로 이전하면 오라클 애플리케이션의 성능이 크게 향상된다.또한 유니시스와 같은 많은 서버 업체들은 서버를 구입하기 이전에 새 프로세서의 성능을 테스트해 보라는 취지로 고객의 생산 시스템을 미리 가동시키도록 허용하고 있다.64비트 프로세서의 장점은 다음과 같다.

RAM 어드레싱 용량 개선 : 32비트 열 크기는 2^32, 즉 4GB 용량의 RAM 주소를 표기하고 데이터를 넣을 수 있다. 64비트 서버는 20GB를 넘어 SGA 영역을 어드레스할 수 있게 해준다
CPU 속도 향상 : 인텔의 64비트 아이태니엄 2 아키텍처는 이전 32비트 칩셋보다 빠르다. 칩의 속도 향상이 오로지 64비트 아키텍처 때문이라고 말할 수는 없지만 연산 집약적인 데이터베이스를 구매하려는 기업들에게는 중요한 고려사항이다
높은 병렬도 : 다중 CPU와 SMP 지원을 이용해 대규모 병렬 처리가 가능하다
파일 입출력 속도 향상 : 64비트 아키텍처는 큰 데이터 블록을 십분 활용한다. BOB(Big Oracle Blocks)는 32k 크기의 블록까지 허용하며 오라클의 색인에 접근하기 위한 디스크 입출력 시간을 크게 줄여준다

RAM 어드레싱 개선만 바라보고 64비트 아키텍처를 수용할 수도 있지만 모든 오라클 데이터베이스가 초대형 데이터 버퍼로 이득을 보진 않는다는 것을 기억해야 한다.데이터 버퍼, 크다고 좋은 건 아니다64비트 프로세서의 주요 시장은 64비트 기종의 RAM 어드레싱 개선점을 요구하는 업체들이다. 대형 오라클 OLTP 업체들이 2GB SGA 영역에서 동작하는 일은 드물지 않으며 이 경우 데이터에 초고속으로 접근하기 위해 주요 정보를 캐시에 저장한다. 그러나 초대형 RAM 영역은 누구에게나 필요한 것은 아니다.30GB 용량의 db_cache_size는 OLTP 업체나 대형 워킹 세트를 사용하는 업체에게 적당하지만 초대형 SGA는 데이터웨어하우스나 의사결정 지원 시스템(DSS)에는 도움이 되지 않는다. 이 프로그램들은 주로 풀-테이블을 스캐닝해 데이터에 접근하기 때문이다.오라클이 풀-테이블 스캔을 수행하는 경우 데이터베이스 블록은 PGA(Program Global Area)로 직접 읽혀 들어가며 데이터 버퍼 RAM은 경유하지 않는다는 점을 명심하라.알다시피 모든 64비트 서버는 대형 열 크기(2^64)를 갖는다. 따라서 180억GB, 즉 18EB(엑사바이트, 10억GB)까지 허용한다. 따라서 초대형 RAM 데이터 버퍼를 만들려는 유혹에 빠질 수 있다.그러나 초대형 db_cache_size 에 따르는 단점이 있다는 사실도 상기할 필요가 있다. 데이터 직접 접근은 해싱(hashing)을 통해 이뤄진다. 그러나 데이터베이스가 RAM 캐시에 존재하는 모든 블록을 검사해야 되는 경우도 있다. 바로 다음과 같은 경우다.

높은 실패율을 가진 시스템 : 프로그램이 잘라진 테이블을 내놓는 경우, 임시 테이블을 사용하는 경우, 그리고 큰 데이터를 퍼지(purge)하는 경우 오라클은 db_cache_size 내의 모든 블록을 쓸어내 오염된 블록을 제거한다. 이 작업은 10GB를 넘어가는 db_cache_size를 가진 시스템에 상당한 무리를 야기한다.
자주 업데이트되는 시스템 : DBWR(Database Writer) 프로세스는 비동기식 기록을 수행할 경우 db_cache_size 내의 블록을 모두 쓸어내야 한다. 거대한 db_cache_size를 갖게 되면 데이터베이스 쓰기 프로세스에 과다한 부하를 가져온다.
RAC 시스템 : 오라클 9i RAC은 초대형 버퍼 RAM와 그다지 궁합이 맞지 않는다. 대형 db_cache_size를 다중 RAC 인스턴스(instances)에서 사용할 경우 크로스-인스턴스 호출이 높아질 수 있다. 인스턴스 사이에 존재하는 ‘핑(ping)’은 과도한 부하를 초래할 수 있기 때문에 RAC 데이터베이스 관리자들은 RAC 인스턴스를 분리해 데이터베이스 내의 특정 영역을 접근하려 하지 않는다.

만약 시스템이 위와 같은 특성 중 몇몇을 갖고 있음에도 불구하고 대형 SGA를 사용하길 원한다면 특별한 연산을 이용해 특정 프로세스가 진행되는 순간 RAM에 가해지는 스트레스를 덜어줘야 한다.대형 데이터를 검사해 제거하고 잘라내는 시스템이나 이런 동작 이전에 데이터 버퍼 캐시의 크기를 줄일 수 있다면 오라클 10g에서는 버퍼를 활성화시키고 리스팅 A에 있는 코드를 사용해 데이터 버퍼 영역의 크기를 조종해줄 수 있다.32비트와 64비트 환경 혼용할 수 있다이전에 오라클 애플리케이션 10i라 불렸던 오라클 애플리케이션 서버 10g와 같은 대형 오라클 애플리케이션의 경우 32비트 환경과 64비트 환경이 혼재하는 상황은 상당히 빈번히 일어나는 일이다. 예를 들어 백엔드 데이터베이스와 인프라스트럭처 데이터베이스는 64비트 시스템하에서 동작하며 HTTP 서버나 웹 캐시 서버는 32비트에서 수행될 수도 있다.만약 시스템이 아래 조건에 해당한다면 32비트 서버를 그대로 유지하는게 낫다.

선형 프로세스 수행 : 다중 CPU SMP 프로세스(오라클 병렬 쿼리)가 대형 테이블이나 풀-테이블 스캔에 필요하지 않는 경우
대형 데이터 버퍼의 필요성 없음 : OLTP 데이터베이스와 같은 대형 워킹 세트가 없다면 32비트가 옳은 선택일 것이다
외부 병목 지점 존재 : 32비트 아키텍처에서는 병목 지점이 오라클 데이터베이스가 아니라면 아무런 문제가 없다. ERP 시스템에서 병목은 애플리케이션 서버, 웹 캐시, 네트워크에 존재할 수 있으며 데이터베이스가 빨라진다고 해서 상황이 나아지는 것은 아무것도 없다
높은 버퍼 실패율 : 만약 애플리케이션이 데이터 검사·제거, 데이터 자름을 자주 수행한다면, 그리고 임시 테이블을 대량으로 사용한다면 대형 RAM 영역이 적합하지 않을 수 있다
계산량이 많지 않은 경우 : 병목 지점이 네트워크나 디스크 입출력에 있다면 64비트 CPU는 전체 성능에 도움이 되지 않는다

역으로 이러한 조건에 해당되지 않는다면 64비트 아키텍처 도입을 신중히 고려해볼 수 있다.64 비트 서버가 만병 통치약은 아니다. 그러나 64비트 프로세서로 이전해야 하는 이유는 문서로 잘 정리돼 있다. 만약 다음 조건 중 몇몇에 해당된다면 64비트 솔루션도 검토해볼만 하다.

높은 트랜잭션 프로세스 비율: 초당 200 번 정도 디스크 입출력 동작을 행하는 시스템이라면 속도나 확장성 측면에서 극적으로 향상될 수 있다. 대량의 데이터를 캐시하게 되면 디스크 입출력은 줄어들고 성능은 매우 좋아진다
성능저하 : 시스템이 커질수록 32비트 시스템이 갖는 한계는 지속적인 확장에 걸림돌이 된다
빠른 확장이 예상됨 : 지속적인 성장과 확장성이 필요한 시스템의 경우 64비트 아키텍처는 거의 무한대의 확장성을 보장해준다. 다수의 대형 ERP 시스템은 64비트 기반 윈도우 플랫폼으로도 성공적으로 확장된 바 있다
연산 집약적 시스템 : 오라클 데이터베이스가 CPU에 영향을 많이 받거나 병렬로 풀-테이블 스캔을 해야 한다면 64비트 아키텍처의 고성능 프로세서는 매우 매력적일 수 있다

결론적으로 오라클 데이터베이스를 64비트 버전으로 전환하는 것은 모든 오라클 시스템이 이익이 되는 것은 아니다. 현명한 오라클 전문가라면 오라클 소프트웨어를 64비트 버전으로 업그레이드하기 전에 전환에 따른 사항들을 조심스레 고려해야 할 것이다. @