SharePoint Server 2010에 대한 데이터베이스 유지 관리

 

마지막으로 수정된 항목: 2016-11-30

요약:  Microsoft SharePoint 2010 제품용 데이터 및 구성 설정을 호스팅하는 데이터베이스를 유지 관리하는 방법에 대해 알아봅니다. 권장 데이터베이스 유지 관리 전략 및 작업에 대한 지침과 예제가 제공됩니다.

적용 대상: Microsoft SharePoint Server 2010, Microsoft SharePoint Foundation 2010

작성자: Bill Baer, Bryan Porter

기술 검토자: Paul S. Randal(SQLskills.com(영문일 수 있음))

목차

  • 소개

  • DBCC(데이터베이스 콘솔 명령) CHECKDB를 사용하여 일관성 오류 확인

  • DBCC CHECKDB

  • DBCC CHECKDB와 성능

  • 인덱스 조각화 측정 및 줄이기

  • 온라인/오프라인 인덱스 다시 작성 비교

  • SQL Server 2008 또는 2005 데이터베이스(sys.dm_db_index_physical_stats)의 조각화 측정

  • 데이터베이스의 조각화 줄이기

  • 특정 테이블 및 해당 인덱스의 조각화 줄이기

  • 채우기 비율을 설정하여 인덱스 설정 미세 조정

  • 데이터 파일 축소

  • SQL Server 2008 유지 관리 계획 만들기

  • 결론

참고

데이터베이스 유지 관리 작업을 구현하거나 SharePoint 2010 데이터베이스를 수정하기 전에 Office 서버 제품 및 Windows SharePoint Services에서 사용하는 데이터베이스 변경 지원의 내용을 확인하십시오.

소개

Microsoft SharePoint 2010 데이터베이스가 원활하게 작동하도록 하려면 일상적으로 데이터베이스를 유지 관리해야 합니다.

SharePoint 2010 데이터베이스에 대한 권장 유지 관리 작업은 다음과 같습니다.

  • 데이터베이스 무결성 검사

  • 인덱스를 다시 구성하거나 다시 작성하여 조각 모음

  • 서버의 채우기 비율 설정

참고

이 문서에서는 데이터베이스 유지 관리에 대해 설명하며 용량 또는 성능 계획에 대해서는 설명하지 않습니다. 용량 또는 성능 계획에 대한 자세한 내용은 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)을 참조하십시오.

이전 버전 SharePoint 제품 및 기술에서는 인덱스 조각 모음 및 통계 유지 관리를 수동으로 수행해야 했지만, SharePoint 2010에서는 다양한 SharePoint 상태 분석기 규칙을 통해 이러한 프로세스가 자동화되었습니다. 이러한 규칙은 데이터베이스 인덱스 및 통계의 상태를 매일 평가하며 다음 데이터베이스에 대해 해당 항목의 문제를 자동으로 해결합니다.

  • 구성 데이터베이스

  • 콘텐츠 데이터베이스

  • User Profile Service 응용 프로그램 프로필 데이터베이스

  • User Profile Service 응용 프로그램 공유 데이터베이스

  • Web Analytics Service 응용 프로그램 보고 데이터베이스

  • Web Analytics Service 응용 프로그램 준비 데이터베이스

  • Word Automation Services 데이터베이스

Transact-SQL 명령 또는 데이터베이스 유지 관리 마법사를 실행하여 데이터베이스 유지 관리 작업을 수행할 수 있습니다. 이 문서에서는 사용 가능한 Transact-SQL 명령에 대해 먼저 설명한 다음, Microsoft SQL Server 데이터베이스 유지 관리 마법사를 사용하여 데이터베이스 유지 관리 계획을 만드는 방법에 대해 설명합니다. Microsoft SQL Server 2008 R2 및 Microsoft SQL Server 2005용으로 자세한 예제가 제공됩니다.

DBCC(데이터베이스 콘솔 명령) CHECKDB를 사용하여 일관성 오류 확인

일상적인 유지 관리 작업에서는 먼저 일관성 검사를 수행하여 데이터와 인덱스가 손상되지 않았는지를 확인합니다. DBCC(데이터베이스 콘솔 명령) CHECKDB 문을 사용하여 데이터 및 인덱스 페이지에 대한 내부 일관성 검사를 수행할 수 있습니다.

대부분의 데이터베이스 일관성 문제는 I/O 하위 시스템 오류로 인해 발생합니다. 그러나 다른 요인과 이벤트도 데이터베이스 일관성에 영향을 줄 수 있습니다(예: 데이터베이스 서버를 비정상적으로 종료하거나 드라이브에서 장애가 발생하는 경우). 기본 데이터베이스 일관성 문제가 있으면 성능과 가용성이 체감 가능한 수준으로 떨어질 수 있습니다. SharePoint 2010 데이터베이스에 대해 매주 한 번 이상, 그리고 데이터베이스 서버 또는 I/O 하위 시스템 장애 등의 이벤트가 발생할 때 데이터베이스 일관성 검사를 수행하십시오.

DBCC CHECKDB

DBCC CHECKDB는 다음 작업을 수행하여 지정된 데이터베이스의 모든 개체에 대해 논리적/물리적 무결성을 검사합니다.

  • DBCC CHECKALLOC에 해당하는 명령을 실행하여 데이터베이스의 할당 구조를 확인합니다.

  • 데이터베이스의 모든 테이블과 보기에 대해 DBCC CHECKTABLE에 해당하는 명령을 실행하여 해당 논리적/물리적 무결성을 확인합니다.

  • 데이터베이스에 대해 DBCC CHECKCATALOG에 해당하는 명령을 실행하여 데이터베이스의 메타데이터 일관성을 확인합니다.

개별 작업(DBCC CHECKALLOC, DBCC CHECKTABLE, DBCC CHECKCATALOG 명령)이 아닌 DBCC CHECKDB를 실행하는 것이 좋습니다. DBCC CHECKDB는 가장 폭넓은 발생 가능 오류를 식별하므로 프로덕션 환경에서 실행해도 안전하기 때문입니다.

DBCC CHECKDB는 메모리, I/O 및 CPU 리소스를 많이 사용합니다. DBCC CHECKDB를 프로덕션 시스템에서 실행하는 대신 다른 서버에 있는 SharePoint 데이터베이스의 복원된 백업에 대해 실행하면 프로덕션 시스템에서 일관성 검사로 인한 작업량을 줄일 수 있습니다.

먼저 DBCC CHECKDB를 실행한 다음 오류가 발견되면 최신 백업을 사용하여 해당하는 데이터베이스를 복원하는 것이 좋습니다.

중요

DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS를 실행할 수는 없지만 DBCC_CHECKDB WITH REPAIR_FAST 및 REPAIR_REBUILD를 실행할 수는 있습니다. 이 두 명령은 연결된 데이터베이스에서만 인덱스를 업데이트하기 때문입니다.

아래에는 DBCC CHECKDB의 예제 출력이 나와 있습니다.

DBCC results for 'Contoso_Content_1'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".
DBCC results for 'sys.sysrowsets'.
There are 309 rows in 4 pages for object "sys.sysrowsets".

...more

CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

SQL Server 2008에서 DBCC CHECKDB를 사용하는 방법에 대한 자세한 내용은 DBCC CHECKDB(Transact-SQL)를 참조하십시오.

DBCC CHECKDB와 성능

DBCC CHECKDB는 리소스(I/O, CPU, 메모리, tempdb 공간)를 매우 많이 사용하므로 프로덕션 작업을 수행하지 않는 시간 동안 일관성 검사를 실행하는 것이 좋습니다. 일반적으로 DBCC CHECKDB에는 차단 잠금이 설정된다는 오해가 많은데 SQL Server 2000부터는 DBCC CHECKDB에 차단 잠금이 설정되지 않습니다. 자세한 내용은 SQL Server DBA에 대한 선입견: (2/30) DBCC CHECKDB로 인해 차단이 발생함(영문일 수 있음)을 참조하십시오.

DBCC CHECKDB를 실행할 때 프로덕션 시스템에서 리소스가 너무 많이 사용되는 경우에는 일관성 검사를 한 번에 한 테이블씩 실행하지 마십시오. 프로덕션 시스템에 대한 무결성 검사의 오버헤드를 줄이는 가장 효율적인 방법은 다음 옵션 중 하나를 사용하는 것입니다.

  • WITH PHYSICAL_ONLY 옵션을 사용하여 CPU 및 메모리 사용량을 줄입니다.

  • 별도의 SQL Server에서 데이터베이스 백업을 복원하고 복원된 데이터베이스 복사본에 대해 일관성 검사를 실행합니다.

이러한 옵션에 대한 자세한 내용은 Paul S. Randal의 블로그 게시물인 CHECKDB 상세 정보: VLDB용 일관성 검사 옵션(영문일 수 있음)을 참조하십시오.

인덱스 조각화 측정 및 줄이기

인덱스 조각화는 인덱스 키로 정의되는 테이블이나 인덱스의 논리적 페이지 순서가 데이터 파일의 물리적 페이지 순서와 다른 경우에 발생합니다. 또한 데이터 파일 페이지의 데이터 밀도가 낮아 디스크 공간, 메모리 및 I/O가 낭비됨을 의미할 수도 있습니다. 테이블에 대해 삽입, 업데이트 또는 삭제 작업을 여러 차례 수행하면 인덱스 조각화가 발생할 수 있습니다. 아래 그림에서는 새로 작성된 조각화되지 않은 인덱스와 삽입, 업데이트, 삭제를 여러 차례 반복하여 조각화된 인덱스를 비교하여 보여 줍니다. 빨간색 화살표는 인덱스의 물리적 순서이고 검은색 화살표는 인덱스 페이지의 논리적 순서입니다.

그림 1. 조각화되지 않은 인덱스(이미지 출처: Paul S. Randal)

조각화되지 않은 인덱스

 

그림 2. 조각화된 인덱스(이미지 출처: Paul S. Randal)

조각화된 인덱스

 

삽입, 업데이트 및 삭제는 테이블과 인덱스의 행에 균일하게 분산되지 않으므로 시간이 경과함에 따라 각 페이지의 사용률(데이터 밀도)이 달라질 수 있습니다. 테이블의 인덱스 전체 또는 일부를 검색하는 쿼리를 수행하는 경우 페이지가 조각화되어 있으면 페이지를 추가로 읽으므로 병렬 데이터 검색을 수행하지 못해 검색 성능이 크게 떨어질 수 있습니다.

인덱스 조각화로 인해 성능이 저하되고 공간 사용 효율성이 떨어질 수 있으며 그다지 많이 사용하지 않는 데이터베이스에서도 인덱스가 빠르게 조각화될 수 있습니다.

인덱스 조각화 유지 관리 계획을 구현하기 전에 조각화 정도가 가장 심한 테이블 및 인덱스를 파악한 다음 해당 인덱스를 다시 작성하거나 다시 구성하는 유지 관리 계획을 작성합니다.

예를 들어 SharePoint 2010에서는 AllDocs 테이블이 조각화되기 쉽습니다. 이 테이블은 문서 라이브러리, 관련 문서 및 목록과 목록 항목, 그리고 개별 메타데이터를 포함합니다.

인덱스의 조각화 수준은 논리적 순서와 물리적 순서가 같지 않은 인덱스 페이지의 비율입니다.

온라인/오프라인 인덱스 다시 작성 비교

온라인 인덱스 다시 작성 기능은 SQL Server Enterprise, Developer 및 Evaluation 버전에서만 사용할 수 있습니다. 이 문서에서 설명하는 방법은 이러한 제한을 고려합니다. 이 문서의 절차에서는 특정 데이터베이스를 호스팅하는 SQL Server 버전이 온라인 인덱스 다시 작성을 지원하지 않거나 다시 작성 중인 인덱스가 온라인 인덱스 다시 작성에 적합하지 않은 경우 오프라인 인덱스 다시 작성을 사용합니다. 데이터 형식이 NVARCHAR(MAX), IMAGE 등인 열과 같이 LOB(큰 개체) 열이 있는 인덱스의 경우 온라인 다시 작성에 적합하지 않습니다.

온라인 인덱스 다시 작성에 대한 자세한 내용은 온라인 인덱스 작동 방식을 참조하십시오. 오프라인 인덱스 다시 작성을 수행하면 다시 작성 프로세스 중에 테이블 수준 잠금이 적용되므로 테이블에 데이터를 쓰거나 액세스하지 못하게 될 수 있습니다. SharePoint 데이터베이스에 있는 대부분의 인덱스는 LOB 열로 인해 항상 오프라인 인덱스 다시 작성 방식으로 다시 작성됩니다.

온라인 인덱스 다시 작성을 사용하는 경우에도 작업 중에 테이블 잠금이 일시적으로 적용되는 두 지점이 있으며, 이로 인해 테이블 액세스가 차단될 수 있습니다. 따라서 인덱스 다시 작성 작업은 항상 작업량이 적은 기간으로 예약하는 것이 좋습니다.

SQL Server 2008 또는 2005 데이터베이스(sys.dm_db_index_physical_stats)의 조각화 측정

SQL Server 2008 또는 SQL Server 2005에서는 sys.dm_db_index_physical_stats 동적 관리 보기를 사용하여 지정된 테이블이나 보기의 인덱스에 대한 조각화를 파악합니다.

조각화를 측정하는 경우 avg_fragmentation_in_percent 열을 모니터링하는 것이 좋습니다. 최고의 성능을 유지하려면 avg_fragmentation_in_percent의 값이 최대한 0에 가까운 것이 좋습니다. 일반적으로는 0~10%의 값이면 적절합니다. 자세한 내용은 sys.dm_db_index_physical_stats를 참조하십시오.

아래 표에는 sys.dm_db_index_physical_stats의 예제 결과가 나와 있습니다. 맨 아래 행에 avg_fragmentation_in_percent의 값이 9.375로 표시됩니다.

database_id

index_type_desc

alloc_unit_type_

desc

avg_fragmentation_

in_percent

10

CLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

CLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

CLUSTERED INDEX

IN_ROW_DATA

9.375

sys.dm_db_index_physical_stats 동적 관리 보기를 사용하려면

  1. 작업 표시줄에서 시작을 클릭하고 모든 프로그램, Microsoft SQL Server 2008을 차례로 가리킨 다음 SQL Server Management Studio를 클릭합니다.

    sys.dm_db_index_physical_stats를 데이터베이스 개체와 함께 사용하려면 데이터베이스 ID와 개체 ID를 알아야 합니다.

  2. 개체 탐색기에서 콘텐츠 데이터베이스를 선택하고 새 쿼리를 클릭한 후에 다음 스크립트를 실행합니다.

    SELECT DB_ID() AS [Database ID];

    참고

    데이터베이스 이름을 지정하지 않고 DB_ID를 사용하는 경우 현재 데이터베이스의 호환성 수준이 100(SQL Server 2008 데이터베이스) 또는 90(SQL Server 2005 데이터베이스)이어야 합니다. 이전 버전 SQL Server에서 업그레이드한 경우에는 DB_ID 문에 데이터베이스 이름을 지정해야 합니다. 호환성 수준에 대한 자세한 내용은 sp_dbcmptlevel(Transact-SQL)을 참조하십시오.

  3. 선택한 데이터베이스 또는 개체에 대해 sys.dm_db_index_physical_stats를 실행합니다. 데이터베이스를 지정할 수 있으며 테이블이나 인덱스도 지정할 수 있습니다.

    sys.dm_db_index_physical_stats를 실행할 때는 다음 구문을 사용합니다.

    sys.dm_db_index_physical_stats ( 
        { database_id | NULL | 0 | DEFAULT }
        , { object_id | NULL | 0 | DEFAULT }
        , { index_id | NULL | 0 | -1 | DEFAULT }
        , { partition_number | NULL | 0 | DEFAULT }
        , { mode | NULL | DEFAULT }
    )
    

    sys.dm_db_index_physical_stats DMV는 리소스를 매우 많이 사용하므로 사용 시 주의해야 합니다. DMV를 사용하는 다양한 방식에 대해 설명하는 포괄적 가이드는 sys.dm_db_index_physical_stats 정보(영문일 수 있음)를 참조하십시오.

데이터베이스의 조각화 줄이기

인덱스 조각화 수준을 낮추려면 다음 지침을 따르십시오.

데이터베이스 유지 관리 상태 분석기 규칙 실행

SharePoint 2010에는 상태 분석기 규칙 프레임워크가 포함되어 있습니다. 이 프레임워크는 SharePoint 환경의 상태를 모니터링하는 여러 규칙을 포함하며, 일부 경우에는 특정 종류의 문제를 해결하기 위한 조치를 취합니다.

SharePoint 2010에는 콘텐츠 데이터베이스 유지 관리와 관련된 여러 규칙이 포함되어 있습니다. 그 중에는 일부 SharePoint 데이터베이스의 인덱스 조각화를 자동으로 줄이는 규칙도 있고, 오래된 통계를 확인하여 필요한 경우 업데이트하는 규칙도 있습니다. 이러한 상태 분석기 규칙은 SharePoint 제품 및 기술 서비스 팩 2에 도입되었던 업데이트된 데이터베이스 통계 타이머 작업을 대체합니다. 기본적으로 이러한 규칙은 규칙 대상에 따라 매일/매주/요청 시 등의 일정으로 실행되도록 구성됩니다.

매일 실행되도록 구성되어 있으며 특정 SharePoint 서비스와 연결된 모든 상태 분석기 규칙은 동일한 타이머 작업을 통해 실행됩니다. 이 타이머 작업의 일정을 조정하면 매일 실행되도록 구성되어 있으며 해당 서비스에 연결된 상태 분석기 규칙이 하루 중 실행되는 시간이 조정됩니다. 이 문서에서 설명하는 모든 규칙은 SharePoint Timer Service에 연결되어 있습니다.

매주 등의 다른 시간 간격으로 실행되도록 구성되어 있거나 다른 서비스에 연결된 상태 분석기 규칙은 다른 타이머 작업을 포함합니다. 매주 실행되도록 구성된 상태 분석기 규칙은 연결된 특정 서비스에 대해 매주 실행되도록 구성된 타이머 작업과 함께 실행됩니다. 즉, 규칙은 타이머 작업에 대해 정의된 일정으로 실행됩니다.

중앙 관리의 상태 분석기 규칙 페이지에 있는 리본 메뉴에서 지금 실행을 클릭하면 상태 분석기 규칙을 수동으로 실행할 수 있습니다. 이러한 규칙을 실행하면 인덱스 및 통계의 상태를 평가하며 필요한 경우 인덱스를 다시 작성하고 다시 계산하기도 합니다.

SharePoint에서 사용하는 데이터베이스에 조각화된 인덱스가 있습니다. 이 규칙을 실행하면 다음 작업이 수행됩니다.

  • 이 규칙은 인덱스를 조각화된 것으로 보고합니다. 인덱스 상태를 평가하는 것은 비용이 많이 드는 작업이므로 상태 분석기 규칙이 실행되고 나면 이 규칙은 항상 인덱스를 조각화된 것으로 보고하여 해결 작업을 트리거합니다.

  • 각 SharePoint 데이터베이스에 대해 이 규칙 작업은 proc_DefragmentIndices 저장 프로시저를 찾으며 저장 프로시저가 있으면 실행합니다. 그러면 데이터베이스에 있는 모든 인덱스의 목록이 작성됩니다. 각 인덱스에서 현재 조각화 수준을 평가하며, 조각화 비율이 30%를 초과하는 인덱스의 경우 다시 작성을 고려합니다.

  • SQL Server 버전에서 온라인 인덱스 다시 작성을 지원하는 경우 각 인덱스에 대해 온라인 인덱스 다시 작성을 시도합니다. 기본 인덱스가 LOB 열로 인해 온라인 다시 작성을 지원하지 않는 등의 원인으로 다시 작성이 실패하면 오프라인 인덱스 다시 작성이 수행됩니다.

앞에서 설명한 것처럼 이 규칙은 SharePoint 환경의 모든 데이터베이스에 대해 실행되지는 않습니다. 특정 데이터베이스는 이와 유사한 유지 관리 작업을 수행하는 데 다른 규칙을 사용합니다.

검색 - 속성 데이터베이스 하나 이상에 조각화된 인덱스가 있습니다. 이 규칙은 SharePoint 2010 엔터프라이즈 검색 속성 데이터베이스의 인덱스를 유지 관리합니다. 기본적으로 이 규칙은 팜의 모든 서버에 대해 매주 실행되도록 구성됩니다. 문제 해결 작업을 비롯한 이 규칙의 모든 처리 작업은 규칙의 Check 단계에서 수행됩니다. 즉, 엔터프라이즈 검색 속성 데이터베이스의 인덱스 다시 작성을 관리하려면 단순히 이 규칙이 인덱스를 자동으로 다시 작성하지 않도록 구성하는 것만으로는 부족합니다. SharePoint 2010에서 인덱스 유지 관리 작업을 자동으로 실행하지 않도록 하려면 규칙 자체를 완전히 사용하지 않도록 설정해야 합니다.

Search - One or more property databases have fragmented indices를 실행하면 다음 작업이 수행됩니다.

  • 규칙은 환경이 인덱스 다시 작성을 수행해도 안전한 상태인지를 확인합니다.

  • 로컬 팜의 검색 응용 프로그램에 대해 구성된 각 속성 데이터베이스에 대해 규칙은 proc_MSS_DefragSearchIndexes 저장 프로시저를 실행하며, 그러면 평균 조각화 비율이 10%보다 높은 모든 인덱스의 목록이 작성됩니다.

  • 속성 데이터베이스 성능에 영향을 주는 목록의 각 인덱스가 다시 작성됩니다. SQL Server 버전이 온라인 인덱스 다시 작성을 지원하면 온라인 인덱스 다시 작성이 수행되고, 온라인 인덱스 다시 작성을 시도했는데 실패하면 인덱스는 오프라인으로 다시 작성됩니다.

검색 - 크롤링 데이터베이스 하나 이상에 조각화된 인덱스가 있을 수 있습니다. 이 규칙은 SharePoint 2010 엔터프라이즈 검색 속성 데이터베이스의 인덱스를 유지 관리합니다. 기본적으로 이 규칙은 팜의 모든 서버에 대해 매주 실행되도록 구성됩니다. 문제 해결 작업을 비롯한 이 규칙의 모든 처리 작업은 규칙의 Check 단계에서 수행됩니다. 즉, 엔터프라이즈 검색 속성 데이터베이스의 인덱스 다시 작성을 관리하려면 단순히 이 규칙이 인덱스를 자동으로 다시 작성하지 않도록 구성하는 것만으로는 부족합니다. SharePoint 2010에서 인덱스 유지 관리 작업을 자동으로 실행하지 않도록 하려면 규칙 자체를 완전히 사용하지 않도록 설정해야 합니다.

Search - One or more property databases have fragmented indices를 실행하면 다음 작업이 수행됩니다.

  • 규칙은 환경이 인덱스 다시 작성을 수행해도 안전한 상태인지를 확인합니다.

  • 로컬 팜의 검색 응용 프로그램에 대해 구성된 각 속성 데이터베이스에 대해 규칙은 proc_MSS_DefragSearchIndexes 저장 프로시저를 실행하며, 그러면 평균 조각화 비율이 10%보다 높은 모든 인덱스의 목록이 작성됩니다.

  • 속성 데이터베이스 성능에 영향을 주는 목록의 각 인덱스가 다시 작성됩니다. SQL Server 버전이 온라인 인덱스 다시 작성을 지원하면 온라인 인덱스 다시 작성이 수행되고, 온라인 인덱스 다시 작성을 시도했는데 실패하면 인덱스는 오프라인으로 다시 작성됩니다.

검색 - 크롤링 데이터베이스 하나 이상에 조각화된 인덱스가 있을 수 있습니다. 이 규칙은 SharePoint 엔터프라이즈 검색 크롤링 데이터베이스의 인덱스를 유지 관리합니다. 기본적으로 이 규칙은 요청 시에만 실행되도록 구성되며, 실행 시에는 팜의 어느 서버에서나 실행할 수 있습니다.

데이터베이스에서 조각화를 확인하는 것은 비용이 많이 드는 작업이므로 이 규칙은 크롤링 데이터베이스의 인덱스를 조각화된 것으로 보고합니다. 이 규칙에 대해 단순히 '복구' 작업만 사용하지 않도록 설정하면 크롤링 데이터베이스의 인덱스를 최근에 작성했더라도 보고서에서 모든 크롤링 데이터베이스가 비정상적인 상태로 표시됩니다.

크롤링 데이터베이스의 인덱스를 수동으로 유지 관리하려면 Search - One or more crawl databases may have fragmented indices 규칙을 완전히 사용하지 않도록 설정하십시오.

Search - One or more crawl databases may have fragmented indices를 실행하면 다음 작업이 수행됩니다.

  • 규칙은 환경이 인덱스 다시 작성을 수행해도 안전한 상태인지를 확인합니다.

  • 로컬 팜의 검색 응용 프로그램에 대해 구성된 각 크롤링 데이터베이스에 대해 규칙이 proc_MSS_DefragGathererIndexes 저장 프로시저를 실행합니다.

  • 목록에 있는 크롤링 데이터베이스의 각 인덱스가 다시 작성됩니다. SQL Server 버전이 온라인 인덱스 다시 작성을 지원하면 온라인 인덱스 다시 작성이 수행되고, 온라인 인덱스 다시 작성을 시도했는데 실패하면 인덱스는 오프라인으로 다시 작성됩니다.

중요

Search - One or more crawl databases may have fragmented indices 규칙은 조각화 수준에 관계없이 모든 크롤링 데이터베이스의 인덱스를 모두 다시 작성합니다. 또한 크롤링 데이터베이스를 호스팅하는 SQL Server 버전에서 지원하는 경우 페이지 수준 데이터 압축도 사용하도록 설정합니다.

크롤링 데이터베이스는 특성상 대개 조각 모음을 자주 수행하지 않아도 됩니다. 콘텐츠에 대해 전체 크롤링을 처음으로 수행한 후에 이 규칙을 실행하고, 그 후에는 크롤링 데이터베이스의 인덱스가 조각화되는지를 모니터링하다가 인덱스 조각화 비율이 높아지면 이 규칙을 실행합니다. 많은 양의 크롤링된 콘텐츠를 갑자기 추가하거나 제거하면 인덱스가 조각화될 수 있습니다. 환경 정리로 인해 콘텐츠가 삭제되거나, 파일 공유 또는 대형 SharePoint 웹 응용 프로그램 등의 새 콘텐츠 원본이 추가된 후를 예로 들 수 있습니다.

다음 데이터베이스의 경우에는 자동화된 유지 관리 메커니즘이 없으며 보통 조각화가 많이 발생하지 않습니다. 이러한 데이터베이스는 조각화를 모니터링하다가 조각화 비율이 30%를 초과하면 데이터베이스의 인덱스를 다시 작성하면 됩니다.

  • 검색 관리 데이터베이스

  • 보안 저장소 데이터베이스

  • State Service 데이터베이스

  • 프로필 동기화 데이터베이스

  • 사용 현황 데이터베이스

  • 관리되는 메타데이터 데이터베이스

  • Business Connectivity Services 데이터베이스

  • PerformancePoint Services 데이터베이스

SharePoint 2010 데이터베이스에 대해 지원되는 변경에 대한 자세한 내용은 Microsoft 기술 자료에서 Office 서버 제품 및 Windows SharePoint Services에서 사용하는 데이터베이스 변경 지원을 참조하십시오.

조각 모음을 자주 수행해도 매우 많이 조각화된 데이터베이스나 테이블의 성능이 그다지 개선되지 않으면 I/O 하위 시스템 성능을 확인해야 합니다.

특정 테이블 및 해당 인덱스의 조각화 줄이기

전체 데이터베이스가 아닌 특정 테이블에 연결된 인덱스에 대해 조각 모음을 수행하려면 해당 인덱스를 다시 작성하거나 다시 구성하면 됩니다.

  • 인덱스를 다시 구성하면 인덱스 리프 수준을 다시 구성하도록 지정됩니다. 인덱스를 다시 구성하면 클러스터형 및 테이블과 보기의 비클러스터형 인덱스가 조각 모음 및 압축되며, 인덱스 검색 성능을 크게 높일 수 있습니다. 인덱스를 다시 구성할 때는 인덱스에 할당된 기존 공간이 사용됩니다. 다시 구성은 항상 온라인으로 수행되므로 사용자가 기본 테이블을 사용할 수 있습니다.

  • 인덱스를 다시 작성하면 인덱스의 새 복사본이 작성되도록 지정됩니다. 따라서 다시 작성 작업을 수행하려면 이전의 조각화된 인덱스를 제거하기 전에 새 인덱스 복사본을 작성하는 데 충분한 공간이 필요합니다. 인덱스를 다시 작성하면 인덱스 검색 및 찾기 성능이 향상됩니다. 온라인이나 오프라인으로 테이블과 함께 인덱스를 다시 작성할 수 있습니다.

인덱스의 조각화 수준에 따라 조각 모음에 사용하는 방법 및 인덱스를 온라인 상태로 유지할 수 있는지 아니면 오프라인으로 전환해야 하는지가 결정됩니다. 아래 표에는 각 조각화 수준에 권장되는 조각 모음 방법에 대한 설명이 나와 있습니다.

조각화 수준 조각 모음 방법

10%까지

다시 구성(온라인)

10-75%

다시 작성(온라인)

75%

다시 작성(오프라인)

참고

SharePoint 2010 데이터베이스에 대해서는 DROP INDEX 및 CREATE INDEX 명령을 사용할 수 없습니다.

SQL Server 2008 또는 SQL Server 2005 ALTER INDEX 문을 사용하거나 SQL Server 2008 또는 SQL Server 2005 유지 관리 계획 마법사를 사용하여 인덱스를 다시 구성하고 다시 작성할 수 있습니다. 이 문서에서는 SQL Server 2008 또는 SQL Server 2005 옵션에 대해서만 자세히 설명합니다.

ALTER INDEX 사용

데이터베이스 관리자는 ALTER INDEX를 사용하여 기존 테이블 또는 보기 인덱스에 대해 유지 관리 작업을 수행할 수 있습니다. ALTER INDEX를 사용하면 인덱스를 다시 작성/다시 구성/비활성화할 수 있으며 인덱스에 대한 옵션을 설정할 수도 있습니다. 대부분의 경우에는 데이터베이스가 온라인 상태일 때 인덱스를 다시 작성할 수 있으며, 그러면 오프라인 인덱스 다시 작성에 비해 사용자에게 더 많은 데이터를 제공할 수 있습니다.

중요

SQL Server 2000에서는 인덱스 유지 관리를 위해 DBCC DBREINDEX 및 DBCC INDEXDEFRAG가 지원되었지만, 이들 명령은 SQL Server 2005부터 더 이상 사용되지 않으며 이후 SQL Server 버전에서는 제거될 예정입니다. 따라서 이러한 명령을 사용하여 SharePoint 2010 데이터베이스에 대해 인덱스 유지 관리를 수행하지 마십시오.

참고

인덱스를 오프라인으로 다시 작성할 때는 테이블에 대해 공유 테이블 잠금이 적용되어 SELECT 이외의 모든 작업이 차단됩니다. SharePoint 2010 데이터베이스는 클러스터된 인덱스를 사용하는데, 클러스터된 인덱스를 오프라인으로 다시 작성할 때는 테이블에 단독 테이블 잠금이 적용되어 사용자가 테이블에 액세스할 수 없게 됩니다.

다음 예제 스크립트를 사용자 지정하여 테이블의 모든 인덱스를 다시 작성할 수 있습니다.

USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO

채우기 비율을 설정하여 인덱스 설정 미세 조정

인덱스 데이터 저장소 및 성능을 보다 개선하려면 채우기 비율을 사용합니다. 인덱스를 만들거나 다시 작성할 때는 채우기 비율 값(1-100)에 따라 각 리프 수준 페이지에서 데이터를 채울 수 있는 공간의 비율이 결정됩니다. 나머지 공간은 이후 확장을 위해 예약됩니다. 대부분의 경우에는 기본 서버 차원 채우기 비율 수준인 0(각 페이지를 100% 채움)이 가장 적합합니다. 그러나 SharePoint 2010에서는 확장을 지원하고 조각화를 최소화하기 위해 서버 차원 설정으로 80을 사용하는 것이 가장 좋습니다.

참고

개별 테이블 또는 인덱스에 대해서는 채우기 비율을 설정하지 않는 것이 좋습니다. SharePoint 이외의 SQL Server 데이터베이스에서는 이 방법이 기본적으로 사용되지만, 테스트 결과 SharePoint 데이터베이스는 채우기 비율이 80%일 때 가장 효율적으로 작동하는 것으로 확인되었습니다.

인덱스 하나 이상의 채우기 비율 값을 보려면 sys.indexes 카탈로그 보기를 쿼리합니다. 이 보기에 대한 자세한 내용은 sys.indexes(Transact-SQL)를 참조하십시오.

서버 차원 채우기 비율 값을 구성하려면 sp_configure 시스템 저장 프로시저를 사용합니다. 자세한 내용은 spconfigure(Transact-SQL)를 참조하십시오.

데이터 파일 축소

SQL Server 2008 및 SQL Server 2005에서는 데이터베이스의 각 파일(파일 이름 확장명 .mdf, .ldf, .ndf)을 축소하여 사용되지 않는 페이지를 제거하고 디스크 공간을 복구할 수 있습니다. SharePoint 2010 데이터베이스에서는 데이터 파일을 자동으로 축소하지 않지만, 대부분의 작업을 수행할 때는 데이터베이스에 사용되지 않는 공간이 만들어집니다. 사용되지 않는 공간을 생성할 수 있는 작업으로는 Move-SPSite Windows PowerShell 명령 실행, 문서/문서 라이브러리/목록/목록 항목/사이트 삭제 등이 있습니다.

그림 3. 데이터베이스 할당

데이터베이스 할당

 

사용 가능한 공간은 파일 끝에서만 확보할 수 있습니다. 예를 들어 크기가 60GB이고 지정된 목표 크기가 40GB인 콘텐츠 데이터베이스 파일의 경우 데이터베이스 파일 끝(개념적으로는 '오른쪽' 끝) 20GB에서 공간을 최대한 확보합니다. 끝 20GB에 사용된 페이지가 있는 경우 해당 페이지는 나중에 파일에서 유지되는 시작 40GB 부분으로 재배치됩니다. 데이터베이스 파일은 개별적으로 또는 그룹으로 축소할 수 있습니다.

축소 작업은 빈번하게 수행해서는 안 됩니다. 데이터베이스에서 많은 데이터를 제거하는 작업을 수행했으며 그로 인해 생성된 사용 가능한 공간을 다시 사용하지 않으려는 경우에만 축소 작업을 수행해야 합니다. 데이터 파일 축소 작업을 수행하면 인덱스가 크게 조각화되며 리소스가 매우 많이 사용됩니다. 특정 콘텐츠 데이터베이스에 있는 많은 수의 사이트 모음을 다른 콘텐츠 데이터베이스로 재배치하거나 큰 목록을 삭제하는 등의 경우에 데이터베이스 파일을 축소할 수 있습니다. 이러한 작업을 수행하면 사용되지 않는 공간이 많이 생성될 수 있습니다. 데이터베이스 파일은 사용 가능한 공간이 더 이상 남지 않는 지점까지만 축소할 수 있습니다. 따라서 콘텐츠를 거의 삭제하지 않는 콘텐츠 데이터베이스의 경우에는 축소해도 별다른 이점을 얻을 수 없으며, 특별히 공간을 추가하지 않고 데이터를 더 포함하기 위해 해당 데이터베이스를 확장해야 하는 경우에는 성능이 저하될 수 있습니다. 자세한 내용은 데이터베이스 파일 초기화를 참조하십시오.

축소를 수행하면 인덱스가 조각화되므로 데이터베이스 파일을 정기적으로 축소해서는 안 됩니다. 대신 데이터베이스에서 사용되는 공간의 상대적인 양에 크게 영향을 주는 작업으로 인해 사용되지 않는 공간이 많이 생성된 경우에만 데이터베이스 파일을 축소합니다. 그러나 가능하면 데이터베이스를 축소하지 마십시오.

데이터베이스를 축소해야 하는 경우에는 다음 지침을 따르십시오.

  • 데이터베이스를 자동으로 축소하지 말고, 프로그래밍 방식으로 데이터베이스를 축소하는 유지 관리 계획을 구성하지 마십시오.

  • 사용자나 관리자가 콘텐츠를 절반 이상 제거했으며 사용되지 않는 공간을 다시 사용할 계획이 없는 경우에만 데이터베이스를 축소하십시오.

  • 콘텐츠 데이터베이스만 축소하십시오. 사용자와 관리자는 보통 구성 데이터베이스, 중앙 관리 콘텐츠 데이터베이스 및 사용 가능한 공간을 많이 포함하는 여러 서비스 응용 프로그램 데이터베이스에서 데이터를 많이 삭제하지 않습니다.

  • 데이터베이스를 축소할 때는 리소스를 매우 많이 사용하므로 데이터베이스를 반드시 축소해야 하는 경우에는 축소 작업을 신중하게 예약해야 합니다.

  • 데이터베이스를 축소하고 나면 해당 데이터베이스의 인덱스가 조각화됩니다. 조각화 문제를 해결하려면 ALTER INDEX… REORGANIZE를 사용합니다. 빠른 파일 초기화를 허용하도록 구성되어 있지 않은 경우 단기간에 예상되는 데이터베이스 확장에 필요한 크기를 수용할 수 있는 대상 크기로 데이터베이스를 축소합니다. 자세한 내용은 데이터베이스 파일 초기화를 참조하십시오.

SQL Server 2008 또는 SQL Server 2005 Management Studio에서 DBCC SHRINKFILE 및 DBCC SHRINKDATABASE 문을 실행하면 데이터베이스 및 데이터베이스 파일을 수동으로 축소해 공간을 복구할 수 있습니다.

데이터베이스를 축소하면 성능이 저하되므로 반드시 필요한 경우가 아니면 축소를 수행해서는 안 되는 이유에 대한 자세한 내용은 데이터 파일을 축소해서는 안 되는 이유(영문일 수 있음)를 참조하십시오.

Transact-SQL 명령을 사용하여 데이터베이스 축소

DBCC SHRINKDATABASE는 특정 데이터베이스의 데이터 및 로그 파일을 축소합니다. 개별 파일을 축소하려면 DBCC SHRINKFILE을 사용합니다.

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE는 다음 구문을 사용합니다.

DBCC SHRINKDATABASE 
( 'database_name' | database_id | 0 
     [ ,target_percent ] 
     [ , { NOTRUNCATE | TRUNCATEONLY } ] 
)
[ WITH NO_INFOMSGS ]

database_name | database_id | 0은 데이터베이스 이름이나 ID를 지정합니다. 현재 데이터베이스를 선택하려면 0을 사용합니다.

target_percent는 데이터베이스 축소 후 유지할 사용 가능한 공간(백분율)입니다.

NOTRUNCATE는 페이지 끝의 할당된 페이지를 페이지 맨 앞의 할당되지 않은 페이지로 이동하여 데이터 파일의 데이터를 압축합니다.

TRUNCATEONLY는 파일 끝에 있는 모든 사용 가능한 공간을 운영 체제로 해제하되 파일에서 페이지 이동은 수행하지 않습니다.

참고

SharePoint 2010 콘텐츠 데이터베이스에는 TRUNCATEONLY 옵션을 사용할 수 없습니다.

자세한 내용은 DBCC SHRINKDATABASE(Transact-SQL)를 참조하십시오.

DBCC SHRINKFILE

DBCC SHRINKFILE은 다음 구문을 사용합니다.

DBCC SHRINKFILE 
(
     { 'file_name' | file_id } 
    { [ , EMPTYFILE ] 
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH NO_INFOMSGS ]

file_name | file_id는 파일 이름이나 ID를 지정합니다.

EMPTYFILE은 모든 데이터를 지정한 파일에서 같은 파일 그룹의 다른 파일로 마이그레이션합니다.

중요

SharePoint 2010 데이터베이스 파일에는 EMPTYFILE 옵션을 사용할 수 없습니다.

target_size는 파일의 목표 크기(MB, 정수로 표시됨)입니다.

NOTRUNCATE는 페이지 끝의 할당된 페이지를 페이지 맨 앞의 할당되지 않은 페이지로 이동하여 데이터 파일의 데이터를 압축합니다.

TRUNCATEONLY는 파일 끝에 있는 모든 사용 가능한 공간을 운영 체제로 해제하되 파일에서 페이지 이동은 수행하지 않습니다.

중요

SharePoint 2010 콘텐츠 데이터베이스에는 TRUNCATEONLY 옵션을 사용할 수 없습니다.

자세한 내용은 DBCC SHRINKFILE(Transact-SQL)을 참조하십시오.

SQL Server 2008 Management Studio를 사용하여 데이터베이스 축소

다음 절차를 수행합니다.

SQL Server 2008 Management Studio를 사용하여 데이터베이스를 축소하려면

  1. 작업 표시줄에서 시작, 모든 프로그램, Microsoft SQL Server 2008, SQL Server Management Studio를 차례로 선택합니다.

  2. 개체 탐색기에서 SQL Server 2008 데이터베이스 엔진의 인스턴스에 연결한 다음 해당 인스턴스를 확장합니다.

  3. 데이터베이스를 확장하고 축소할 데이터베이스를 마우스 오른쪽 단추로 클릭한 다음 작업, 축소, 파일을 차례로 선택합니다.

  4. 파일 형식과 파일 이름을 선택합니다.

  5. 사용하지 않은 공간을 해제하기 전에 파일 다시 구성을 선택합니다. 파일 축소 값도 선택해야 합니다. 파일에서 사용되지 않는 모든 공간을 운영 체제로 해제하고 행을 할당되지 않은 페이지로 재배치하려면 이 옵션을 선택합니다.

  6. 확인을 클릭합니다.

SQL Server 2008 유지 관리 계획 만들기

SQL Server 유지 관리 계획을 구현하면 이 문서에서 설명하는 대부분의 데이터베이스 유지 관리 작업을 프로그래밍 방식으로 적용할 수 있습니다. 유지 관리 계획은 데이터를 보호하는 데 필요한 태스크를 자동화하고 예약할 수 있습니다. 관리자는 SQL Server 2008 또는 SQL Server 2005에서 유지 관리 계획을 사용하여 데이터베이스 일관성 검사 실행, 인덱스 다시 구성/다시 작성 등의 작업을 예약할 수 있습니다. 자세한 내용은 다음 리소스를 참조하십시오.

SQL Server 2008 데이터베이스 유지 관리 계획을 구성하려면

  1. 작업 표시줄에서 시작, 모든 프로그램, Microsoft SQL Server 2008, SQL Server Management Studio를 차례로 선택합니다.

  2. 개체 탐색기에서 SQL Server 2008 데이터베이스 엔진의 인스턴스에 연결한 다음 해당 인스턴스를 확장합니다.

  3. 관리를 선택하고 유지 관리 계획을 마우스 오른쪽 단추로 클릭한 후에 유지 관리 계획 마법사를 선택합니다.

  4. 계획 속성 선택 페이지가 표시될 때까지 계속 다음을 선택합니다.

    그림 4. 계획 속성 선택 페이지

    계획 속성 선택 페이지

  5. 이름설명 필드에 이름과 설명을 지정합니다.

  6. 하나 이상의 유지 관리 계획을 구성할지 여부를 결정합니다.

    • 유지 관리 계획 하나를 구성하려면 전체 계획에 하나의 일정 또는 일정 없음을 선택합니다.

    • 특정 태스크를 포함하여 여러 개의 유지 관리 계획을 구성하려면 각 태스크에 별도의 일정을 선택합니다.

    콘텐츠 데이터베이스가 10개 이상이거나 콘텐츠가 200GB 이상인 환경의 경우에는 별도의 유지 관리 계획을 구성하여 해당 환경에 적합한 고유 작업을 적용하고 유지 관리 창을 최대화하는 것이 좋습니다. .

    하나의 데이터베이스에 대해 여러 유지 관리 계획을 구성하는 경우 일정을 비롯하여 해당 계획 및 용도를 구분할 수 있는 이름과 설명을 지정합니다.

  7. 변경을 클릭하여 하나 이상의 계획에 대해 일정을 설정합니다.

    작업 일정 속성 대화 상자가 나타납니다.

    그림 5. 작업 일정 속성 대화 상자

    작업 일정 속성 대화 상자

  8. 일정을 완성하고 확인, 다음을 차례로 클릭합니다.

  9. 유지 관리 태스크 선택 페이지에서 계획에 포함할 유지 관리 태스크를 선택하고 다음을 클릭합니다.

    그림 6. 유지 관리 태스크 선택 페이지

    유지 관리 태스크 선택 페이지

    다음 참고 사항을 고려하십시오.

    • 유지 관리 계획에는 인덱스 다시 구성 또는 다시 작성 중 하나만 포함해야 합니다.

    • 유지 관리 계획에는 데이터베이스 축소를 포함할 수 없습니다.

    • 각 태스크의 기간을 결정하려면 태스크를 단일 계획으로 결합하기 전에 각 태스크를 개별적으로 테스트합니다. 사용자의 작업 성능을 저하시키지 않는 시간 중에 태스크를 완료할 수 있도록, 별도의 일정으로 여러 유지 관리 계획을 정의해야 할 수 있습니다.

    • 유지 관리 정리 태스크는 예약 유지 관리 이후 남아 있는 파일을 제거합니다.

  10. 유지 관리 태스크 순서 선택 페이지에서 필요한 경우 유지 관리 계획 태스크의 순서를 변경합니다. 이렇게 하려면 태스크를 선택하고 위로 이동 또는 아래로 이동을 클릭합니다. 태스크 순서를 원하는 대로 지정한 후에 다음을 클릭합니다.

    참고

    데이터베이스가 매우 큰 경우에는 인덱스 유지 관리보다 낮은 빈도로 데이터베이스 무결성을 검사하는 별도의 유지 관리 계획을 작성할 수 있습니다.

    그림 7. 유지 관리 태스크 순서 선택 페이지

    유지 관리 태스크 순서 선택 페이지

  11. 다음으로 마법사에는 각 태스크의 세부 정보를 설정하는 페이지가 표시됩니다. 데이터베이스 무결성 검사 태스크 정의 페이지에서 무결성을 검사할 데이터베이스를 선택하고 다음을 클릭합니다.

    참고

    모든 SharePoint 2010 데이터베이스의 무결성을 안전하게 검사할 수 있습니다.

    그림 8. 데이터베이스 무결성 검사 태스크 정의 페이지

    데이터베이스 무결성 검사 태스크 정의 페이지

  12. 인덱스 다시 구성 태스크 정의 페이지의 데이터베이스 목록에서 인덱스를 다시 구성할 데이터베이스를 지정하고 큰 개체 압축 확인란을 선택한 후에 다음을 클릭합니다.

    그림 9. 인덱스 다시 구성 태스크 정의 페이지

    인덱스 다시 구성 태스크 정의 페이지

  13. 인덱스를 다시 구성하지 않고 다시 작성하려면 인덱스 다시 작성 태스크 정의 페이지의 데이터베이스 목록에서 데이터베이스를 지정합니다.

  14. 페이지당 빈 공간 비율을 다음으로 변경을 선택하고 80을 입력한 후에 다음을 클릭합니다.

    페이지당 빈 공간 비율을 다음으로 변경은 데이터베이스의 채우기 비율을 설정합니다.

    그림 10. 인덱스 다시 작성 태스크 정의 페이지

    인덱스 다시 작성 태스크 정의 페이지

  15. 유지 관리 정리 태스크 정의 페이지에서 요청된 값을 지정하고 다음을 클릭합니다.

    유지 관리 계획 텍스트 보고서는 삭제하는 것이 좋습니다.

    그림 11. 유지 관리 정리 태스크 정의 페이지

    유지 관리 정리 태스크 정의 페이지

  16. 보고서 옵션 선택 페이지에서 텍스트 파일에 보고서 쓰기를 선택하고 파일 위치를 선택한 후에 다음을 계속 클릭하여 마법사를 완료합니다.

    그림 12. 보고서 옵션 선택

    보고서 옵션 선택

결론

SharePoint 2010을 호스팅하는 데이터베이스를 일관성 있게 유지 관리하면 시스템 성능과 상태가 크게 개선될 수 있습니다.

유지 관리 작업 및 유지 관리 계획을 구현하기 전에 모든 데이터베이스에 대해 신뢰할 수 있는 백업을 만들어야 합니다.

유지 관리 계획 또는 지속적으로 실행되는 특정 유지 관리 작업을 구현하기 전에 해당 작업의 시스템에 대한 영향 및 작업을 실행하는 데 필요한 시간을 테스트합니다.

사용자의 성능에 대한 영향을 최소화하기 위해 최대한 사용량이 적은 시간에 유지 관리 작업 또는 유지 관리 계획을 실행하도록 설정합니다.

See Also

Other Resources

이 항목 다운로드