Microsoft SQL Server는 SQL Server의 이벤트를 모니터링하고 물리적 데이터베이스 디자인을 튜닝하는 데 사용할 종합적인 도구 세트를 제공합니다. 수행할 모니터링 또는 튜닝 유형 및 모니터링할 특정 이벤트에 따라 도구 선택이 달라집니다. 예상 성능을 보장하려면 최소한 일정 간격으로 통계가 생성되어야 합니다.

자세한 내용은 다음 링크를 참조하십시오. https://docs.microsoft.com/en-us/sql/relational-databases/performance/performance-monitoring-and-tuning-tools?view=sql-server-2017 >

실패 후 데이터를 복원하고 복구하는 데 사용할 수 있는 SQL Server 데이터의 복사본입니다. SQL Server 데이터의 백업은 데이터베이스 또는 하나 이상의 파일이나 파일 그룹의 수준에서 생성됩니다. 테이블 수준의 백업은 생성할 수 없습니다. 전체 복구 모델에서는 데이터 백업 이외에도 트랜잭션 로그의 백업을 생성해야 합니다.

데이터베이스의 트랜잭션 로그 유지 관리를 제어하는 데이터베이스 속성입니다. 복구 모델은 세 가지로 단순, 전체 및 대량 로그가 있습니다. 데이터베이스의 복구 모델에 따라 백업 및 복원 요구사항이 결정됩니다.

지정된 SQL Server 백업의 모든 데이터 및 로그 페이지를 지정된 데이터베이스에 복사한 다음 로깅된 변경 사항을 적용해 백업에 로깅된 모든 트랜잭션을 롤포워드하여 정시에 맞춰 데이터를 가져오는 다단계 프로세스입니다.

자세한 내용은 다음을 참조하십시오.

확장성은 보다 유용한 작업을 수행하기 위해 더 많은 리소스를 효율적으로 사용하기 위한 응용 프로그램의 기능입니다.

SQL Server에서 구현할 수 있는 가장 간단한 확장 솔루션은 확장 가능한 공유 데이터베이스입니다. 이 시나리오에서는 SAN에서 데이터베이스를 생성하고, 서로 다른 서버에서 실행 중인 SQL Server 인스턴스(최대 8개)를 데이터베이스에 연결되고, 쿼리 처리를 시작합니다. 이는 일반적인 "공유 디스크" 스타일의 확장 솔루션으로, 처리 성능은 확장되지만 데이터의 단일 디스크 이미지만 사용됩니다. 이때 SQL Server에 익숙한 사용자라면 "그렇다면 잠금은 어떻게 되나요? 각 SQL Server 인스턴스는 자체 메모리에 자체 잠금을 유지한다고 알고 있습니다."라는 질문을 할 수 있습니다. 맞는 말입니다. 각 인스턴스는 자체 데이터베이스 잠금을 유지 관리하고 어떤 인스턴스도 다른 인스턴스의 잠금에 대해 인식하지 못합니다. 이는 잠금이 없는 경우에만 작동하는 방법이므로 확장 가능한 공유 데이터베이스는 데이터베이스가 읽기 전용 데이터베이스로 연결되어 있는 경우에만 작동합니다. 즉, 확장 가능한 공유 데이터베이스는 데이터 웨어하우스 또는 보고 데이터베이스에는 매우 적합하지만 데이터를 업데이트하는 응용 프로그램에는 적합하지 않습니다. 데이터 특성을 다시 살펴보면 확장 가능한 공유 데이터베이스는 업데이트 간격이 0인 경우에만 작동한다는 사실을 확인할 수 있습니다. 이 데이터는 정의상 기록 데이터이므로 모두 참조 데이터입니다.

MSSQL Server에서 인덱스 키의 최대 바이트 수는 900바이트를 초과할 수 없습니다. 최대 크기가 900바이트를 초과해서 추가되는 가변 길이 열을 사용하여 키를 정의할 수는 있지만 이 경우에는 해당 열에 900바이트를 넘는 데이터가 있는 행을 삽입해서는 안 됩니다. (https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2014&redirectedfrom=MSDN).