[지디넷코리아]만약 현 시스템으로 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에 있는 코드를 사용해 데이터 버퍼 영역의 크기를 조종해줄 수 있다.