보관 정책 시작하기

증권 보관 및 제거 정책 비교

2단계 프로세스로 생각하는 것이 좋습니다. 먼저 데이터를 보관한 후 최종 삭제를 관리합니다.

정책 보관

보관 정책은 프로덕션에서 보관소로 데이터를 이동하는 기준을 정의합니다. 이 정책을 만들 때 초기 보존 기간도 설정합니다.

보관 정책은 LastModifiedDate > 365 days ago와 같은 단일 조건을 사용하여 보관할 레코드를 식별합니다.

또한 보관 정책은 "보관 날짜 7년 후 삭제"와 같은 단순한 기본 보존 기간을 설정합니다. 보존 기간은 보관된 레코드의 초기 만료 일자를 설정합니다.

정책 제거

삭제 정책은 보관소에 저장된 데이터를 영구적으로 삭제하는 기준을 정의합니다.

제거 정책은 보관 정책에 설정된 기본 보존 기간을 변경하여 데이터 폐기를 관리할 수 있는 더 많은 기능과 유연성을 제공합니다.

예를 들어, 아카이브 정책 중 기본 7년 보존 설정에 관계없이 Record Type = 'Test Data' AND Archived Date > 1 year와 같은 특정 레코드 유형을 더 빨리 제거하고 Record Type = 'Financial' AND Archived Date > 10 years와 같은 더 중요한 레코드를 더 오래 보관할 수 있습니다.

시작하기 전 핵심 질문

좋은 정책은 좋은 계획에서 시작됩니다. 구축을 시작하기 전에 이해당사자와 이러한 주요 질문을 논의하십시오.

보관할 항목은 무엇입니까?

• 보관해야 하는 루트 개체 및 관련 하위 레코드는 무엇입니까? 예를 들어, 마감된 사례, 이전 과업 또는 사용자 정의 프로젝트 레코드가 있습니다.
• 비즈니스 운전자는 누구입니까? 성능을 개선하고 저장소 비용을 절감하거나 특정 규정 준수 요구 사항을 충족하려고 합니까?

실행 시기는 언제입니까?

• 보관 및 제거 정책은 얼마나 자주 실행되어야 합니까? 예: 매일, 매주 또는 매월
• 보관 및 제거 정책이 실행되어야 하는 특정 시간 및 날짜는 무엇입니까?
  

  노트 사용자 및 시스템 성능에 미칠 수 있는 영향을 줄이기 위해 야간 및 주말과 같이 최대 시간 외 시간에 대규모 아카이브 또는 제거 프로세스를 실행하는 것이 좋습니다.

액세스 권한이 있는 사람은 누구입니까?

• 이러한 보관 및 제거 정책을 만들고 관리할 책임이 있는 사람은 누구입니까?
  

  노트 일반적으로 시스템 관리자이지만 적절한 관리자에게 보관 권한 집합을 할당할 수 있습니다.
• 데이터가 보관된 후 누가 데이터를 확인해야 합니까? 관리자, 감사자 또는 특정 지원 팀을 예로 들 수 있습니다.
• 보관에서 레코드를 보관 취소하고 라이브 조직으로 다시 복원하려면 권한이 필요한 사람은 누구입니까?
  

  노트 보관 취소 권한 집합은 이 기능을 제어하며 필요한 특정 사용자에게만 할당해야 합니다.

사용 사례 및 쿼리

테스트를 위해 낮은 보관 정책 제한으로 시작하는 것이 좋습니다.

예 - 과업 보관

개체: 과업

사용 사례: 다음 기준을 충족하는 과업 보관

• 사례의 레코드 유형과 관련
• RecordTypeID = 'abc'
• 2년 넘게 마지막으로 수정됨

LIMIT = 5는 각 실행에서 5개의 작업 및 관련 객체를 보관합니다.

미리 보기: ID, 활동 일자, 범주(사용자 정의 필드), 설명, 소유자 ID, 제목, 상태

SELECT Id FROM Task WHERE Whold IN (SELECT Id FROM Contact 
WHERE RecordTypeid = 'abc') AND ActivityDate<LAST_N_DAYS: 730 LIMIT 5

예 - 사례 보관

개체: 사례

사용 사례: 다음 기준을 충족하는 사례를 보관합니다.

• 상태가 '마감됨'으로 설정됨
• 30일 이상 생성됨

LIMIT = 5000은 각 실행에서 5,000개의 사례와 관련 객체를 보관합니다.

미리 보기: ID, 사례 번호, 유형, 하위 범주(사용자 정의 필드), 문제(사용자 정의 필드)

SELECT Id FROM Case WHERE Status = 'Closed' 
AND CreatedDate < LAST_N_DAYS: 30 LIMIT 5000

예 - 특정 계정에서 사례 보관

개체: 사례

사용 사례: 이 기준을 충족하는 사례를 보관합니다.

• 상태가 '마감됨'으로 설정됨
• 30일 이상 생성됨
• ID 번호 '1234'가 있는 계정에 속합니다.

LIMIT = 5000은 각 실행 및 관련 객체에 5,000개의 사례를 보관합니다.

미리 보기: ID, 사례 번호, 유형, 하위 범주(사용자 정의 필드), 문제(사용자 정의 필드)

SELECT Id FROM Case WHERE accountId IN (SELECT id from Account 
WHERE Id ='1234XXXXXXXXXXXXXXX') AND Status = 'Closed' 
AND CreatedDate < Last_N_Days:30 LIMIT 5000

예 - 첨부 파일 보관

개체: 첨부 파일

사용 사례: 다음 위치에서 첨부 파일을 보관합니다.

• 상위는 ' Signed Off' 또는 'Asbestos Completed' 단계의 기회입니다.
• 기회 완료 일자가 6개월 이상 지난 날짜입니다.

LIMIT = 2500는 각 실행에서 2,500개의 첨부 파일 및 관련 객체를 보관합니다.

미리 보기: ID, 상위 ID, 만든 날짜

SELECT Id FROM Attachment WHERE ParentId IN (SELECT Id FROM Opportunity 
WHERE (StageName='Signed Off' OR StageName='Asbestos Completed') 
AND CloseDate < N_MONTHS_AGO:6) LIMIT 2500

예 - 연락처 보관

개체: 연락처

사용 사례: 다음 위치에서 연락처를 보관합니다.

• Archiver__c 필드가 True로 설정됨

LIMIT = 1000은 각 실행에서 2,500개의 연락처와 관련 객체를 보관합니다.

미리 보기: ID, 상위 ID, 만든 날짜

SELECT Id FROM Contact WHERE Archiver__c = true LIMIT 1000

쿼리 보관 모범 사례

보관 쿼리의 성공을 향상하려면 다음 권장 사항을 고려하십시오.

• 색인화된 필드에 조건을 작성합니다. SOQL 쿼리의 복잡성은 필드의 색인화에 적합한지에 크게 영향을 미칩니다. 표준 색인과 사용자 정의 색인은 다릅니다.
• 쿼리 및 검색 최적화 치트 시트를 참조하십시오.
• 결과 집합을 관리 가능한 크기로 제한합니다. 너무 많은 레코드를 한 번에 검색하면 색인화된 조회보다 상당히 느린 테이블 스캔이 트리거될 수 있습니다.
• 대용량 데이터와 일치하는 필터를 지나치게 넓게 사용하지 마십시오. 필요한 경우 날짜 범위를 더 작은 배치로 분할하여 쿼리 부하를 줄입니다.
• 필터 논리를 정기적으로 확인하여 보관해야 하는 레코드만 대상으로 지정하십시오.
• 프로세스 로그를 모니터링하여 전체 프로세스 수명 주기 동안 진행되지 않는 반복적인 성능 지체 지점 또는 레코드를 식별합니다.
• 날짜를 사용하여 쿼리 결과를 필터링합니다. 자세한 내용은 날짜 형식 및 WHERE의 날짜 문자 기호를 참조하십시오.
• LastModifiedDate가 아닌 SystemModstamp을 참조하십시오.

  LastModifiedDate는 사용자가 레코드를 변경할 때 사용자 중심이며 업데이트됩니다. SystemModstamp는 시스템 중심이며 자동화 및 백엔드 프로세스를 포함하여 시스템에서 레코드를 수정할 때 업데이트됩니다. SystemModstamp를 사용하는 쿼리는 색인화되므로 성능이 더 좋아집니다.

• Force.com 자체 SOQL 쿼리 최적화 프로그램이 있습니다. 자세한 내용은 Lightning Platform 쿼리 최적화 FAQ를 참조하십시오.

보관 쿼리 최적화

Salesforce에서 쿼리를 실행할 때 특히 대규모 데이터 집합에 대해 작업하는 경우 효율성을 향상하고 성능 문제를 방지하기 위해 최적화되어 있는지 확인하는 것이 중요합니다.

일반적인 문제는 특정 필터가 성능에 부정적인 영향을 미치는 전체 테이블 스캔을 트리거할 수 있다는 것입니다. 예:

SELECT Id FROM EmailMessage WHERE ParentId IN (SELECT Id FROM Case 
WHERE IsClosed = true) AND LastModifiedDate < LAST_N_MONTHS:13 LIMIT 350000

이 쿼리에 대한 문제:

• IsClosed는 선택적 필터가 아니므로 색인을 효율적으로 사용하지 않습니다.
• LastModifiedDate는 1,000만 개 이상의 레코드를 반환할 수 있으므로 인덱스를 사용할 수 없습니다.
• 쿼리 최적화를 최대한 활용하려면 Salesforce에서 쿼리된 개체를 색인화해야 합니다.
• 효율성을 향상하려면 IN 하위 쿼리를 제거해야 합니다.

쿼리 최적화:

• 불필요한 복잡성을 줄이는 IN 하위 쿼리를 제거합니다.
• 개체가 색인화되어 있는지 확인합니다.

  색인화되지 않은 개체에 대한 쿼리는 성능 최적화의 혜택을 누리지 않습니다.

• Developer Console에서 쿼리 계획 설정을 활성화합니다.

  쿼리 계획 설정은 쿼리 선택성을 분석합니다. 이 설정을 활성화하려면 Developer Console의 도움말 아래의 기본 설정으로 이동합니다.

• 다음 필터를 수정합니다.
  • 색인화된 필드로 Parent.IsClosed 변경
  • SystemModstamp가 색인화되고 일반적으로 더 효율적이므로 LastModifiedDate 대신 SystemModstamp을 사용하십시오.
  • 스캔된 레코드 수를 줄이려면 날짜 범위를 좁힙니다. 예: <13 및 >15.

다음은 더욱 효율적인 새로운 쿼리입니다.

SELECT Id FROM EmailMessage WHERE Parent.IsClosed = true 
AND LastModifiedDate < LAST_N_MONTHS: <13 and >15 LIMIT 350000