IBAnalyst
IBAnalyst는 이제 HQbird Standard의 일부입니다!
IBAnalyst는 데이터베이스 관리자가 Firebird 또는 InterBase 데이터베이스의 상세 통계를 분석하고 데이터베이스 성능, 유지 관리 및 애플리케이션과 데이터베이스 간의 상호 작용에서 발생할 수 있는 문제를 식별할 수 있게 해주는 도구입니다.
문서
IBAnalyst는 Firebird(또는 InterBase) 데이터베이스 통계를 사용자 친화적인 방식으로 그래픽으로 표시하며 다음과 같은 문제를 강조합니다:
- 테이블 및 BLOB 단편화,
- 레코드 버전 관리,
- 가비지 컬렉션,
- 인덱스 효율성 등
또한 IBAnalyst는 데이터베이스 성능 개선 및 데이터베이스 유지 관리에 대한 지능적인 제안을 자동으로 제공할 수 있습니다.
IBAnalyst는 Services API를 통해 운영 중인 프로덕션 데이터베이스에서 통계를 가져오거나(권장), gstat -a -r … 명령의 텍스트 출력을 분석할 수 있습니다. 최대 부하 기간의 통계는 프로덕션 데이터베이스의 실제 성능 문제에 대한 많은 정보를 제공할 수 있습니다.
IBAnalyst가 Firebird 또는 InterBase 데이터베이스의 문제를 찾는 데 어떻게 도움이 되는지
IBAnalyst의 주요 기능을 살펴보겠습니다. IBAnalyst에서 데이터베이스 통계를 처음 볼 때, 특히 요약, 테이블 및 인덱스 보기에서 빨간색과 노란색 셀로 많은 경고가 표시되면 상황이 명확하지 않을 수 있습니다. 몇 가지 실제 통계 예를 살펴보겠습니다.
요약 보기
요약 페이지에는 많은 정보가 표시되지만 가장 중요한 것은 트랜잭션 상태입니다( IBAnalyst 도움말에서 가능한 트랜잭션 상태에 대한 설명을 읽어보세요. F1을 누르거나 도움말 메뉴에서 확인할 수 있습니다).
이 스크린샷에서 일부 트랜잭션이 오랫동안 활성 상태이며 “일일 평균의 60%“임을 볼 수 있습니다. IBAnalyst는 이러한 트랜잭션 상태를 빨간색으로 표시합니다. 이 트랜잭션이 누적된 버전이 서버에서 가비지로 간주되어 가비지 컬렉션되는 것을 방지할 수 있기 때문입니다. 이것은 속도 저하의 가능한 원인입니다. 특정 레코드에 존재하는 버전이 많을수록 읽는 데 더 많은 시간이 걸립니다.
이 장기 실행 트랜잭션을 찾으려면 FBScanner의 MON$Logger 모듈을 사용하거나 MON$ 테이블을 직접 쿼리할 수 있습니다. 그런 다음 장기 실행 트랜잭션의 영향을 받은 테이블(레코드 버전이 많은 테이블)을 확인하려면 IBAnalyst의 “테이블” 보기로 이동해야 합니다.
테이블 보기
“테이블” 보기에서는 테이블과 해당 테이블의 중요한 매개변수(레코드 수, 레코드 버전 수, 레코드 길이, 최대 버전 수 등)를 볼 수 있습니다.
이 보기를 정렬하여 가장 큰 테이블을 찾을 수 있습니다. 특히 레코드 버전이 많은 테이블에 관심이 있습니다. 레코드 버전이 많으면 영향을 받는 테이블의 가비지 컬렉션이 더 오래 걸립니다. 일반적으로 많은 레코드 버전을 제거하려면 업데이트 및 삭제 알고리즘을 변경해야 합니다.
행 버전은 특정 테이블의 총 버전 수를 표시하고 행 최대 버전은 일부 레코드가 도달한 최대 버전을 표시합니다. 예를 들어 NAB 테이블을 보면 1,190만 개의 레코드가 있고 총 버전은 20,932개이지만 한 레코드에는 176개의 버전이 있습니다. 이러한 패킷을 디스크에서 읽고 구문 분석하는 데 더 많은 시간이 걸리므로 이 레코드를 읽는 것이 다른 레코드를 읽는 것보다 느립니다.
이 그림은 또한 데이터가 삭제된 많은 테이블을 보여줍니다. 그러나 장기 실행 트랜잭션으로 인해 서버가 이러한 버전을 삭제할 수 없으며 여전히 디스크에 있고, 여전히 인덱싱되어 있으며, 데이터를 읽을 때 서버가 여전히 읽고 있습니다.
인덱스 보기
일부 프로덕션 데이터베이스에는 단일 키 값만 인덱싱된 인덱스가 있을 수 있습니다. 이는 데이터베이스가 “향후 확장을 위해” 개발되었거나 누군가 개발 또는 테스트 중에 인덱스를 실험했기 때문에 발생할 수 있습니다. IBAnalyst에서 이러한 인덱스를 “무용지물"로 볼 수 있습니다:
SKIN04, SKIN05, SKOUT03 등은 모든 행(수백만 행)에 대해 하나의 값만 있는 열에 구축된 인덱스입니다. 이러한 인덱스는 정말로 쓸모가 없습니다. 왜냐하면
- “where field = …“을 지정하면 옵티마이저가 이 인덱스를 사용할 수 있습니다. 필드에 하나의 값만 포함되어 있으므로 인덱스를 사용하면 인덱스 페이지를 디스크에서 메모리로 불필요하게 읽게 되고, 서버가 해당 쿼리에 대해 표시할 행을 준비할 때 메모리(및 시간)를 소비하게 됩니다.
- 인덱스 생성은 복원 프로세스의 일부입니다. 추가 인덱스는 추가 시간을 발생시킵니다.
물론 이것이 IBAnalyst에서 데이터베이스에 대해 찾을 수 있는 전부는 아닙니다. 다음도 찾을 수 있습니다:
- 일일 평균 트랜잭션 수
- 롤백이나 연결 끊김이 있었는지, 그리고 언제 발생했는지
- 각 테이블과 인덱스의 크기(메가바이트 단위)
- BLOB과 레코드가 교차되어 있어 레코드만 읽는 것이 더 느린 테이블
- 빈 테이블 - 잊혀졌거나 통계 수집 시점에 비어 있던 테이블
- 중복 키가 많은 인덱스(열 값 분포를 고려할 수 있음)
- 깊이가 4 이상인 인덱스 - 속도를 높이기 위해 페이지 크기를 늘려야 할 수도 있습니다
자동 권장 사항
색상이 지정된 셀 경고를 읽는 것이 혼란스럽다면 “보고서\권장 사항 보기"를 열면 됩니다. 데이터베이스 성능에 필요한 모든 것이 여기에 모여 있습니다. 궁금한 점이 있으면 언제든지 문의하세요( [email protected]).