Blue Prism 데이터베이스 유지 관리의 기초

[BohyonHwang]

Blue Prism 데이터베이스 유지 관리의 기초

https://community.blueprism.com/communities/community-home/digestviewer/viewthread?MessageKey=74efd053-3000-43d3-9570-8721cb02826f&CommunityKey=3743dbaa-6766-4a4d-b7ed-9a98b6b1dd01&tab=digestviewer#bm...

유용한 내용을 번역해 올립니다.

원본의 출처는 위의 주소를 참조하십시오.

원저자는 @Chris McGowan입니다.

Fundamentals of Blue Prism Database Maintenance

Introduction

Blue Prism 데이터베이스는 모든 Blue Prism 배포에서 중요한 구성 요소입니다. Blue Prism 데이터베이스는 사용자, 자격 증명, 프로세스, 객체, 작업 대기열 항목, 세션 로그 및 감사 정보를 저장합니다. 데이터베이스의 성능과 유지 관리가 모든 Blue Prism의 성공적 배포 관리에 매우 중요하다는 것은 놀라운 일이 아닙니다. 그러나 관리가 제대로 이루어지지 않은 데이터베이스와 함께 Blue Prism을 배포하는 경우를 너무 자주 봅니다. 이 게시물은 Blue Prism 데이터베이스 유지 관리의 기본 사항에 대한 고급 가이드를 제공하기 위한 것입니다.

Backups

DBA의 가장 중요한 책임은 회사의 데이터를 보호하는 것입니다. 이는 데이터베이스의 보안뿐만 아니라 데이터베이스가 백업되고 손상되지 않았는지 확인해야 함을 의미합니다. Blue Prism 데이터베이스도 다르지 않습니다. 백업이 필수적이며 비즈니스 기대치에 따라 수행되는 동일한 중요성이 있습니다. DBA는 다양한 복구 모델과 백업 유형을 알고 있어야 하며, 어떻게 사용되며 무엇을 하며 언제 수행해야 하는지 알아야 합니다. Blue Prism 배포를 계획할 때 저는 항상 고객이 플랫폼에 대한 RPO(Recovery Point Objective, 복구 시점 목표) 및 RTO(Recovery Time Objective, 복구 시간 목표)를 정의하도록 조언합니다. 그렇다면 RPO 및 RTO는 정확히 무슨 뜻일까요?

• RPO – 장애 발생 후 데이터를 복구할 수 있는 시점입니다. 나는 이것을 비즈니스 사용자에게 "어느 정도까지 데이터를 잃어도 됩니까?"로 제시하고 싶습니다.
• RTO – 장애가 발생한 후 데이터를 복구할 수 있는 시간입니다. 나는 이것을 비즈니스 사용자에게 "플랫폼이 복구되는 동안 얼마나 오래 기다릴 수 있습니까?"로 제시하고 싶습니다.

이 두 가지 메트릭을 알면 그에 따라 백업 및 복구 계획을 구현할 수 있습니다. 예를 들어, RPO가 1시간인 경우 매일 전체 데이터베이스 백업(차등 또는 트랜잭션 로그 백업 없음)만 수행하는 것은 무의미합니다. 매일 전체 백업만 수행하면 RPO가 24시간인 것처럼 되므로 시간이 단축되지 않습니다! Blue Prism 데이터베이스에 대한 백업 및 복구 계획을 세울 때 다음 사항을 고려하고 구현하는 것이 중요합니다.

• RPO 및 RTO 모두를 정의하십시오.
• RPO에 따라 전체 백업, 변경 분 백업 및 트랜잭션 로그 백업을 허용하는 전체 복구 모델을 만드십시오.
• 모든 백업에서 WITH CHECKSUM 및 VERIFYONLY 옵션을 사용하여 백업이 유효하고 필요한 경우 복원할 수 있다는 확신을 높이십시오.
• WITH COMPRESSION 옵션을 사용하여 디스크 공간을 절약하고 데이터베이스를 백업하고 복원하는 데 걸리는 시간을 줄이십시오.
• 백업 및 복구 프로세스를 문서화 하십시오.
• 백업 테스트를 실시하십시오.

나는 마지막 요점의 중요성을 강조하지 않을 수 없습니다. 백업 테스트는 CHECKSUM 및 VERIFY 옵션을 사용하는 것을 의미하지 않습니다. 실제로 백업을 어딘가에 복원하여 테스트한다는 의미입니다. 이것이 백업이 유효한지 확인하는 유일한 방법입니다. 회사 데이터에 대한 책임을 지고 RPO 및 RTO 요구 사항을 충족하는 백업 및 복구 계획을 갖고 있고 실제로 실패 후 데이터베이스를 복원해야 하고 백업이 손상되었기 때문에 복원할 수 없다는 것을 알게 된다고 상상해 보십시오!

Index Maintenance

Blue Prism 데이터베이스의 대부분의 테이블은 트랜잭션 테이블입니다. 즉, 정적이 아니라 시간이 지남에 따라 자주 변경됩니다. 일반적인 Blue Prism 작업, 프로세스 생성, 릴리스 가져오기, 일정 실행 등을 수행할 때 Blue Prism 응용 프로그램은 Blue Prism 데이터베이스의 이러한 트랜잭션 테이블에 데이터를 삽입하고 수정합니다. 이러한 작업이 발생하면 SQL Server가 데이터베이스 테이블에서 데이터를 읽는 데 사용하는 인덱스에 조각화가 일어납니다. 인덱스 조각화는 인덱스 키 값을 기준으로 한 인덱스 페이지의 논리적 순서가 데이터 파일 내부의 물리적 순서와 일치하지 않을 때 발생합니다. 인덱스 조각화는 트랜잭션 데이터베이스 시스템에서 불가피하며 유지 관리되지 않으면 요청된 데이터를 읽는 데 필요한 디스크 I/O 작업의 양이 불필요하게 증가합니다. Blue Prism의 경우 응용 프로그램이 클라이언트에 결과를 반환하는 데 더 오래 걸리고 프로세스가 실행되는 데 더 오래 걸립니다.

SQL Server는 인덱스를 조각 모음할 때 몇 가지 옵션, 특히 인덱스 재구축 및 인덱스 재구성을 제공합니다. 이 게시물의 범위를 벗어나는 인덱스 재구축과 재구성 사이에는 몇 가지 주요 차이점이 있습니다. Microsoft는 조각화가 30% 미만인 인덱스는 재구성해야 하는 반면 조각화가 30% 이상인 인덱스는 다시 작성해야 한다고 조언합니다.

인덱스 유지 관리는 Blue Prism 솔루션 성능의 핵심이며 아래 지침에 따라 수행해야 합니다.

• 인덱스 유지 관리를 정기적으로, 밤마다, 가능하면 최소한 매주 수행하십시오.
• 운영에 대한 영향을 줄이기 위해 이른 아침 시간과 같이 조용한 시간에 인덱스 유지 관리를 수행합니다.
• 위에서 언급한 30% 임계값을 기반으로 인덱스를 재구성하거나  재구축합니다.
• 인덱스 유지 관리의 일부로 통계 업데이트합니다.
• 가능한 경우 전체 데이터베이스 백업 전에 인덱스 유지 관리를 수행합니다.

Integrity Checks

모든 데이터베이스의 무결성을 확인하는 것은 매우 중요하며 Blue Prism 데이터베이스도 예외는 아닙니다. 수정 조치를 취할 수 있도록 가능한 한 빨리 데이터베이스에 손상이 있는지 알고 싶습니다. 데이터 손상으로 인해 사용자가 잘못된 데이터를 얻거나 쿼리가 실패하거나 전체 SQL Server 인스턴스를 오프라인 상태로 만들 수도 있습니다. 손상은 언제든지 발생할 수 있으며 SQL Server의 문제, Windows의 문제 또는 스토리지 하위 시스템의 문제로 인해 발생할 수 있습니다. 극단적인 경우 손상으로 인해 데이터가 손실될 수 있습니다. 이전 게시물에서 "DBA가 가진 가장 중요한 책임은 회사 데이터를 보호하는 것"이라고 말한 것을 기억하십시오. 손상으로 인해 데이터가 손실되면 데이터를 보호하지 않은 것입니다. 여기서 그치는 것이 아닙니다. 백업에서도 손상이 나타날 수 있으므로 정기적인 무결성 검사를 수행하지 않고 백업 체크섬을 사용하지 않거나 백업을 확인 및 테스트하지 않으면 실제로 데이터 손실 위험이 생깁니다.

다시 말하지만, SQL Server는 DBCC CHECKDB 형식으로 데이터베이스의 무결성을 쉽게 확인할 수 있는 기능을 제공합니다. DBCC CHECKDB는 데이터베이스에 있는 모든 개체의 논리적 및 물리적 무결성을 확인하고 여러 작업을 통해서 이를 수행합니다. 이 작업에 대한 자세한 내용은 이 게시물의 범위를 벗어납니다. Blue Prism 데이터베이스의 무결성을 보장하기 위해 다음을 고려하고 구현하는 것이 중요합니다.

• DBCC CHECKDB를 정기적으로, 이상적으로는 매일, 최소한 매주 실행하십시오.
• 데이터베이스 백업 전에 DBCC CHECKDB를 실행하는 것을 고려하십시오. 이렇게 하면 백업이 일관성이 있다는 확신을 가질 수 있습니다.
• 최신 백업을 다른 서버에서 복원해 보고 이에 대해 DBCC CHECKDB를 실행하는 것을 고려하십시오. 이렇게 하면 일석이조의 효과가 있습니다. 백업을 테스트하고 이에 대해 무결성 검사도 실행하게 됩니다.
• Log Shipping, 데이터베이스 미러링 및 Always On Availability Groups은 DBCC CHECKDB를 실행할 필요성을 제거하지 않습니다. DBCC CHECKDB를 오프로드하는 유일한 유효한 방법은 복원된 전체 백업에 대해 실행하는 것입니다.
• 데이터 손상이 얼마나 심각한지, 손상이 발생했을 때 적절한 조치를 취하는 방법을 이해했는지 확인하십시오.

좋은 소식이 있습니다. 백업, 인덱스 유지 관리 및 무결성 검사를 위해 Ola Hallengren의 SQL Server 유지 관리 솔루션 형태의 유지 관리 솔루션이 사용 가능합니다. SQL Server 유지 관리 솔루션은 2008년부터 2019년까지 모든 버전의 Microsoft SQL Server에서 백업, 무결성 검사, 색인 및 통계 유지 관리를 실행하기 위한 스크립트로 구성됩니다. 이 솔루션은 저장 프로시저를 기반으로 하며 대부분의 미션 크리티컬 업무를 위해 설계되었습니다. 그리고 완전히 문서화되어 있으며 무엇보다도 완전히 무료입니다.

Archiving

Blue Prism Database는 일상 업무에 필요한 모든 비필수 데이터를 보관해야 하므로 리포팅 데이터베이스가 아니라 운영 데이터베이스입니다. 성능 관련 문제의 가장 일반적인 원인 중 하나는 데이터베이스 유지 관리의 부재 때문입니다. 아카이빙은 첫날부터 해결해야 합니다. 즉, 성능 문제를 방지하려면 배포의 일부로 보관 전략을 구현해야 합니다.

세션 로그는 Blue Prism 시스템 설정에서 직접 보관할 수 있습니다.

System Tab → System → Archiving

제품 내 보관에는 두 가지 보관 모드가 있습니다.

• Automatic – 사용자와 상호 작용 없이도 정기적으로 아카이브를 수행할 수 있습니다.
• Manual – 사용자가 필요에 따라 수동으로 보관해야 합니다.

제품 내 아카이빙은 사용자에게 두 가지 옵션을 제공합니다.

• Export – 데이터를 폴더로 내보냅니다.
• Delete – 로그를 내보내지 않고 삭제합니다.

중요하지 않은 운영 데이터를 제거하여 여러 다른 데이터베이스 테이블을 정기적으로 유지 관리하는 것도 매우 중요합니다. 이러한 테이블은 아래에 관련된 데이터가 포함된 테이블입니다.

• Process History
• Work Queues
• Schedules

현재 이러한 추가 테이블은 Blue Prism 인터페이스 내에서 보관할 수 없지만 요청 시 Blue Prism 글로벌 고객 지원에서 제공할 수 있는 TSQL 스크립트입니다. 이러한 스크립트는 예약된 SQL Server 에이전트 작업으로 구현되어 이러한 추가 테이블에서 기록 데이터를 주기적으로 "제거"할 수 있습니다. 일반적으로 예를 들어 저녁과 주말과 같이 시스템 사용률이 낮고 시스템이 완전히 종료되는 동안 대규모 Blue Prism 배포 기간 동안입니다.

#BPTechTips #BP테크팁
#Database #DB #데이터베이스 #백업

------------------------------

Chris McGowan

Senior Technical Consultant

Blue Prism

------------------------------

​​​​​​​