트랜잭션 로그(SQL Server)The Transaction Log (SQL Server)

각 SQL Server 데이터베이스에는 모든 트랜잭션과 각 트랜잭션에 의해 적용된 데이터베이스 수정 내용을 기록하는 트랜잭션 로그가 있습니다.Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.

트랜잭션 로그는 데이터베이스의 중요한 구성 요소입니다.The transaction log is a critical component of the database. 시스템 오류가 발생한 경우 데이터베이스를 일관된 상태로 다시 전환하려면 이 로그가 필요합니다.If there is a system failure, you will need that log to bring your database back to a consistent state.

중요

로그 삭제 또는 이동이 어떤 결과를 의미하는지 완전히 이해하지 않는 한 이 로그를 삭제하거나 이동하지 마세요.Never delete or move this log unless you fully understand the ramifications of doing so.

데이터베이스 복구 중 트랜잭션 로그 적용을 시작할 알려진 올바른 지점은 검사점에 의해 만들어집니다.Known good points from which to begin applying transaction logs during database recovery are created by checkpoints. 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요.For more information, see Database Checkpoints (SQL Server).

트랜잭션 로그가 지원하는 작업Operations supported by the transaction log

트랜잭션 로그는 다음 작업을 지원합니다.The transaction log supports the following operations:

  • 개별 트랜잭션 복구Individual transaction recovery.

  • SQL ServerSQL Server 가 시작될 때 불완전한 모든 트랜잭션 복구Recovery of all incomplete transactions when SQL ServerSQL Server is started.

  • 복원된 데이터베이스, 파일, 파일 그룹 또는 페이지를 오류 지점으로 롤포워드Rolling a restored database, file, filegroup, or page forward to the point of failure.

  • 트랜잭션 복제 지원Supporting transactional replication.

  • 고가용성 및 재해 복구 솔루션 지원: Always On 가용성 그룹Always On availability groups, 데이터베이스 미러링 및 로그 전달Supporting high availability and disaster recovery solutions: Always On 가용성 그룹Always On availability groups, database mirroring, and log shipping.

개별 트랜잭션 복구Individual transaction recovery

응용 프로그램이 ROLLBACK 문을 실행하거나 데이터베이스 엔진이 클라이언트와의 통신이 끊어진 때와 같은 오류를 검색할 경우 불완전한 트랜잭션에 의해 수정된 내용을 롤백하는 데 이 로그 레코드가 사용됩니다.If an application issues a ROLLBACK statement, or if the Database Engine detects an error such as the loss of communication with a client, the log records are used to roll back the modifications made by an incomplete transaction.

SQL ServerSQL Server 가 시작될 때 불완전한 모든 트랜잭션 복구Recovery of all incomplete transactions when SQL ServerSQL Server is started

서버에 장애가 발생하면 데이터베이스에서 일부 수정 내용이 버퍼 캐시에서 데이터 파일로 옮겨지지 않을 수 있으며 데이터 파일에 불완전한 트랜잭션으로 인한 일부 수정 내용이 그대로 남아 있을 수 있습니다.If a server fails, the databases may be left in a state where some modifications were never written from the buffer cache to the data files, and there may be some modifications from incomplete transactions in the data files. SQL Server의 인스턴스가 시작되면 이 인스턴스는 각 데이터베이스의 복구를 실행합니다.When an instance of SQL Server is started, it runs a recovery of each database. 데이터 파일에 쓰여지지 않은 로그에 기록된 모든 수정 내용은 롤포워드됩니다.Every modification recorded in the log which may not have been written to the data files is rolled forward. 그런 다음 트랜잭션 로그에서 발견된 모든 불완전한 트랜잭션이 롤백되어 데이터베이스의 무결성이 보존됩니다.Every incomplete transaction found in the transaction log is then rolled back to make sure the integrity of the database is preserved.

복원된 데이터베이스, 파일, 파일 그룹 또는 페이지를 오류 지점으로 롤포워드Rolling a restored database, file, filegroup, or page forward to the point of failure

데이터베이스 파일에 영향을 주는 하드웨어 손실이나 디스크 오류가 발생한 후 데이터베이스를 오류 발생 지점으로 복원할 수 있습니다.After a hardware loss or disk failure affecting the database files, you can restore the database to the point of failure. 먼저 마지막 전체 데이터베이스 백업과 마지막 차등 데이터베이스 백업을 복원한 후 트랜잭션 로그 백업의 이후 시퀀스를 오류 지점까지 복원합니다.You first restore the last full database backup and the last differential database backup, and then restore the subsequent sequence of the transaction log backups to the point of failure.

각 로그 백업을 복원할 때 데이터베이스 엔진은 로그에 기록된 모든 수정 내용을 다시 적용하여 모든 트랜잭션을 롤포워드합니다.As you restore each log backup, the Database Engine reapplies all the modifications recorded in the log to roll forward all the transactions. 마지막 로그 백업이 복원되면 데이터베이스 엔진은 로그 정보를 사용하여 해당 지점에서 완료되지 않은 모든 트랜잭션을 롤백합니다.When the last log backup is restored, the Database Engine then uses the log information to roll back all transactions that were not complete at that point.

트랜잭션 복제 지원Supporting transactional replication

로그 판독기 에이전트는 트랜잭션 복제를 위해 구성한 각 데이터베이스의 트랜잭션 로그를 모니터링하고 복제 표시된 트랜잭션을 트랜잭션 로그에서 배포 데이터베이스로 복사합니다.The Log Reader Agent monitors the transaction log of each database configured for transactional replication and copies the transactions marked for replication from the transaction log into the distribution database. 자세한 내용은 트랜잭션 복제 작동 방법을 참조하세요.For more information, see How Transactional Replication Works.

고가용성 및 재해 복구 솔루션 지원Supporting high availability and disaster recovery solutions

대기 서버 솔루션, Alwayson 가용성 그룹, 데이터베이스 미러링 및 로그 전달은 트랜잭션 로그를 많이 사용합니다.The standby-server solutions, Always On Availability Groups, database mirroring, and log shipping, rely heavily on the transaction log.

Always On 가용성 그룹 시나리오에서는 주 복제본인 데이터베이스의 모든 업데이트가 보조 복제본인 데이터베이스의 개별 전체 복사본에서 바로 재생성됩니다.In an Always On Availability Group scenario, every update to a database, the primary replica, is immediately reproduced in separate, full copies of the database, the secondary replicas. 주 복제본에서 각 로그 레코드를 보조 복제본으로 바로 보내면 들어오는 로그 레코드를 가용성 그룹 데이터베이스에 적용하여 계속 롤포워드합니다.The primary replica sends each log record immediately to the secondary replicas which applies the incoming log records to availability group databases, continually rolling it forward. 자세한 내용은 Always On 장애 조치(failover) 클러스터 인스턴스를 참조하세요.For more information, see Always On Failover Cluster Instances

로그 전달 시나리오에서는 주 서버가 주 데이터베이스의 활성 트랜잭션 로그를 하나 이상의 대상으로 보냅니다.In a log shipping scenario, the primary server sends the active transaction log of the primary database to one or more destinations. 각 보조 서버는 이 로그를 로컬 보조 데이터베이스로 복원합니다.Each secondary server restores the log to its local secondary database. 자세한 내용은 로그 전달 정보를 참조하세요.For more information, see About Log Shipping.

데이터베이스 미러링 시나리오에서는 주 데이터베이스에 대한 모든 업데이트 내용이 미러 데이터베이스인 데이터베이스의 전체 복사본에 즉시 재생성됩니다.In a database mirroring scenario, every update to a database, the principal database, is immediately reproduced in a separate, full copy of the database, the mirror database. 주 서버 인스턴스에서 로그 레코드를 미러 서버 인스턴스로 즉시 보내면 미러 서버 인스턴스에서는 들어오는 로그 레코드를 미러 데이터베이스에 적용하여 계속 롤포워드합니다.The principal server instance sends each log record immediately to the mirror server instance which applies the incoming log records to the mirror database, continually rolling it forward. 자세한 내용은 데이터베이스 미러링을 참조하세요.For more information, see Database Mirroring.

Transaction Log characteristicsTransaction Log characteristics

SQL Server 데이터베이스 엔진SQL Server Database Engine 트랜잭션 로그의 특성은 다음과 같습니다.Characteristics of the SQL Server 데이터베이스 엔진SQL Server Database Engine transaction log:

  • 트랜잭션 로그는 데이터베이스에서 별도의 파일 또는 파일 집합으로 구현됩니다.The transaction log is implemented as a separate file or set of files in the database. 로그 캐시는 데이터 페이지의 버퍼 캐시와는 별도로 관리되므로 데이터베이스 엔진에 단순하고, 빠르고, 강력한 코드를 구현할 수 있습니다.The log cache is managed separately from the buffer cache for data pages, which results in simple, fast, and robust code within the Database Engine. 자세한 내용은 트랜잭션 로그 물리적 아키텍처를 참조하세요.For more information, see Transaction Log Physical Architecture.
  • 로그 레코드 및 페이지의 형식은 데이터 페이지의 형식을 따르도록 제한되어 있지 않습니다.The format of log records and pages is not constrained to follow the format of data pages.
  • 트랜잭션 로그는 여러 파일에 구현할 수 있습니다.The transaction log can be implemented in several files. 트랜잭션 로그에 FILEGROWTH 값을 설정하여 자동으로 확장되도록 파일을 정의할 수 있습니다.The files can be defined to expand automatically by setting the FILEGROWTH value for the log. 이를 통해 트랜잭션 로그에서 공간이 부족해질 확률이 줄어들며 동시에 관리 오버헤드가 줄어듭니다.This reduces the potential of running out of space in the transaction log, while at the same time reducing administrative overhead. 자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하세요.For more information, see ALTER DATABASE (Transact-SQL).
  • 로그에서 공간을 재사용하는 메커니즘은 빠르게 수행되며 트랜잭션 처리량에 최소의 영향만 미칩니다.The mechanism to reuse the space within the log files is quick and has minimal effect on transaction throughput.

트랜잭션 로그 잘림 Transaction log truncation

로그 잘림은 트랜잭션 로그에서 다시 사용할 수 있도록 로그 파일의 공간을 확보하는 것입니다.Log truncation frees space in the log file for reuse by the transaction log. 할당된 공간이 가득 차지 않도록 트랜잭션 로그를 주기적으로 줄여야 합니다.You must regularly truncate your transaction log to keep it from filling the alotted space (And it will!!)! 몇몇 요소로 인해 로그 잘림이 지연될 수 있으므로 로그 크기를 모니터링하는 것이 중요합니다.Several factors can delay log truncation, so monitoring log size matters. 일부 작업을 최소로 기록하여 트랜잭션 로그 크기에 주는 영향을 줄일 수 있습니다.Some operations can be minimally logged to reduce their impact on transaction log size.

로그 잘림은 SQL ServerSQL Server 데이터베이스의 논리 트랜잭션 로그에서 비활성 가상 로그 파일을 삭제하여 물리적 트랜잭션 로그에서 다시 사용할 수 있도록 논리 로그의 공간을 확보합니다.Log truncation deletes inactive virtual log files from the logical transaction log of a SQL ServerSQL Server database, freeing space in the logical log for reuse by the Physical transaction log. 트랜잭션 로그가 잘리지 않으면 물리적 로그 파일에 할당된 디스크 공간이 모두 채워집니다.If a transaction log is never truncated, it will eventually fill all the disk space allocated to physical log files.

공간 부족 문제를 방지하기 위해 어떤 이유로 로그 잘림이 지연되지 않는 한 다음과 같은 경우에 잘림이 자동으로 수행됩니다.To avoid running out of space, unless log truncation is delayed for some reason, truncation occurs automatically after the following events:

  • 단순 복구 모델에서는 검사점 이후 잘림이 수행됩니다.Under the simple recovery model, after a checkpoint.

  • 전체 복구 모델 또는 대량 로그 복구 모델에서는 이전 백업 이후에 검사점이 발생한 경우 로그 백업 후 잘림이 수행됩니다(복사 전용 로그 백업이 아닌 경우).Under the full recovery model or bulk-logged recovery model, if a checkpoint has occurred since the previous backup, truncation occurs after a log backup (unless it is a copy-only log backup).

    자세한 내용은 이 항목의 뒷부분에 나오는 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.For more information, see Factors That Can Delay Log Truncation, later in this topic.

참고

로그 잘림을 수행해도 물리적 로그 파일의 크기는 줄어들지 않습니다.Log truncation does not reduce the size of the physical log file. 실제 로그 파일의 크기를 줄이려면 로그 파일을 축소해야 합니다.To reduce the physical size of a physical log file, you must shrink the log file. 물리적 로그 파일의 크기를 축소하는 방법은 Manage the Size of the Transaction Log File를 참조하십시오.For information about shrinking the size of the physical log file, see Manage the Size of the Transaction Log File.

Factors that can delay log truncation Factors that can delay log truncation

지금까지 설명했듯이 오랜 시간 동안 로그 레코드가 활성 상태로 유지되는 경우 트랜잭션 로그 잘림이 지연되고 트랜잭션 로그가 가득 찰 수 있습니다.When log records remain active for a long time, transaction log truncation is delayed, and the transaction log can fill up, as we mentioned earlier in this long topic.

[!중요} 가득 찬 트랜잭션 로그에 응답하는 방법에 대한 자세한 내용은 꽉 찬 트랜잭션 로그 문제 해결(SQL Server 오류9002)를 참조하세요.[!IMPORTANT} For information about how to respond to a full transaction log, see Troubleshoot a Full Transaction Log (SQL Server Error 9002).

실제로 여러 이유로 인해 로그 잘림이 지연될 수 있습니다.Really, Log truncation can be delayed by a variety of reasons. 로그 잘림이 발생하지 않는 이유는 sys.databases 카탈로그 뷰의 log_reuse_waitlog_reuse_wait_desc 열을 쿼리하여 확인할 수 있습니다.Learn what, if anything, is preventing your log truncation by querying the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view. 다음 표에서는 이러한 열의 값에 대해 설명합니다.The following table describes the values of these columns.

log_reuse_wait 값log_reuse_wait value log_reuse_wait_desc 값log_reuse_wait_desc value 설명Description
00 NOTHINGNOTHING 현재 다시 사용 가능한 가상 로그 파일이 하나 이상 있습니다.Currently there are one or more reusable virtual log files.
11 CHECKPOINTCHECKPOINT 마지막 로그 잘림이나 로그 헤더가 가상 로그 파일을 넘어서 이동되지 않았기 때문에 검사점이 발생하지No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file. 있습니다(모든 복구 모델).(All recovery models)

로그 잘림 지연을 유발하는 일반적인 이유입니다.This is a routine reason for delaying log truncation. 자세한 내용은 Database Checkpoints (SQL Server)을 참조하세요.For more information, see Database Checkpoints (SQL Server).
22 LOG_BACKUPLOG_BACKUP 트랜잭션 로그를 자르려면 먼저 로그 백업이 필요합니다.A log backup is required before the transaction log can be truncated. 이는 전체 또는 대량 로그 복구 모델의 경우에만 해당됩니다.(Full or bulk-logged recovery models only)

다음 로그 백업이 완료되면 일부 로그 공간이 다시 사용될 수 있습니다.When the next log backup is completed, some log space might become reusable.
33 ACTIVE_BACKUP_OR_RESTOREACTIVE_BACKUP_OR_RESTORE 데이터 백업이나 복원이 진행되고 있습니다(모든 복구 모델).A data backup or a restore is in progress (all recovery models).

데이터 백업으로 인해 로그 잘림이 발생하지 않을 경우 해당 백업 작업을 취소하면 즉시 문제를 해결할 수 있습니다.If a data backup is preventing log truncation, canceling the backup operation might help the immediate problem.
44 ACTIVE_TRANSACTIONACTIVE_TRANSACTION 트랜잭션이 활성 상태입니다(모든 복구 모델).A transaction is active (all recovery models):

로그 백업 시작 시 장기 실행 트랜잭션이 있을 수 있습니다.A long-running transaction might exist at the start of the log backup. 이 경우 공간을 확보하려면 다른 로그 백업이 필요할 수 있습니다.In this case, freeing the space might require another log backup. 트랜잭션 로그가 일반적으로 각 자동 검사점에서 잘리는 단순 복구 모델을 비롯한 모든 복구 모델에서 장기 실행 트랜잭션은 로그 잘림이 수행되지 않도록 합니다.Note that long-running transactions prevent log truncation under all recovery models, including the simple recovery model, under which the transaction log is generally truncated on each automatic checkpoint.

트랜잭션이 지연되었습니다.A transaction is deferred. 지연된 트랜잭션 은 사실상 일부 사용할 수 없는 리소스로 인해 롤백이 차단된 활성 트랜잭션입니다.A deferred transaction is effectively an active transaction whose rollback is blocked because of some unavailable resource. 지연된 트랜잭션의 원인 및 이러한 트랜잭션을 지연된 상태에서 벗어나게 하는 방법에 대한 자세한 내용은 지연된 트랜잭션(SQL Server)을 참조하십시오.For information about the causes of deferred transactions and how to move them out of the deferred state, see Deferred Transactions (SQL Server).

장기 실행 트랜잭션은 tempdb의 트랜잭션 로그를 채울 수도 있습니다.Long-running transactions might also fill up tempdb's transaction log. Tempdb는 정렬을 위한 작업 테이블, 해싱을 위한 작업 파일, 커서 작업 테이블 및 행 버전 관리 등 내부 개체에 대한 사용자 트랜잭션에 의해 암시적으로 사용됩니다.Tempdb is used implicitly by user transactions for internal objects such as work tables for sorting, work files for hashing, cursor work tables, and row versioning. 사용자 트랜잭션에 데이터 읽기(SELECT 쿼리)만 포함되는 경우에도 내부 개체가 만들어져 사용자 트랜잭션 하에서 사용될 수 있습니다.Even if the user transaction includes only reading data (SELECT queries), internal objects may be created and used under user transactions. 그런 다음 tempdb 트랜잭션 로그를 채울 수 있습니다.Then the tempdb transaction log can be filled.
55 DATABASE_MIRRORINGDATABASE_MIRRORING 데이터베이스 미러링이 일시 중지되거나 성능 우선 모드에서는 미러 데이터베이스가 주 데이터베이스보다 훨씬Database mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. 않습니다(전체 복구 모델에만 해당).(Full recovery model only)

자세한 내용은 데이터베이스 미러링(SQL Server)을 참조하세요.For more information, see Database Mirroring (SQL Server).
66 REPLICATIONREPLICATION 트랜잭션 복제 중에 게시와 관련된 트랜잭션이 배포 데이터베이스로 배달되지During transactional replications, transactions relevant to the publications are still undelivered to the distribution database. 않습니다(전체 복구 모델에만 해당).(Full recovery model only)

트랜잭션 복제에 대한 자세한 내용은 SQL Server Replication를 참조하십시오.For information about transactional replication, see SQL Server Replication.
77 DATABASE_SNAPSHOT_CREATIONDATABASE_SNAPSHOT_CREATION 데이터베이스 스냅숏이 생성되고A database snapshot is being created. 있습니다(모든 복구 모델).(All recovery models)

로그 잘림 지연을 유발하는 일반적인 이유입니다.This is a routine, and typically brief, cause of delayed log truncation.
88 LOG_SCANLOG_SCAN 로그 검색이 수행되고A log scan is occurring. 있습니다(모든 복구 모델).(All recovery models)

로그 잘림 지연을 유발하는 일반적인 이유입니다.This is a routine, and typically brief, cause of delayed log truncation.
99 AVAILABILITY_REPLICAAVAILABILITY_REPLICA 가용성 그룹의 보조 복제본에서 해당하는 보조 데이터베이스에 이 데이터베이스의 트랜잭션 로그 레코드를 적용하고A secondary replica of an availability group is applying transaction log records of this database to a corresponding secondary database. 있습니다(전체 복구 모델).(Full recovery model)

자세한 내용은 Always On 가용성 그룹 개요(SQL Server)를 참조하세요.For more information, see Overview of Always On Availability Groups (SQL Server).
1010 내부용으로만 사용할 수 있습니다.For internal use only
1111 내부용으로만 사용할 수 있습니다.For internal use only
1212 내부용으로만 사용할 수 있습니다.For internal use only
1313 OLDEST_PAGEOLDEST_PAGE 데이터베이스가 간접 검사점을 사용하도록 구성된 경우 데이터베이스의 가장 오래된 페이지가 검사점 LSN보다 오래되었을 수 있습니다.If a database is configured to use indirect checkpoints, the oldest page on the database might be older than the checkpoint LSN. 이 경우 가장 오래된 페이지는 로그 잘림이 지연될 수In this case, the oldest page can delay log truncation. 있습니다(모든 복구 모델).(All recovery models)

간접 검사점에 대한 자세한 내용은 Database Checkpoints (SQL Server)을 참조하세요.For information about indirect checkpoints, see Database Checkpoints (SQL Server).
1414 OTHER_TRANSIENTOTHER_TRANSIENT 이 값은 현재 사용되지 않습니다.This value is currently not used.

최소 로깅 가능한 작업 Operations that can be minimally logged

최소 로깅 은 지정 시간 복구를 지원하지 않고 트랜잭션을 복구하는 데 필요한 정보만 기록합니다.Minimal logging involves logging only the information that is required to recover the transaction without supporting point-in-time recovery. 이 항목에서는 대량 로그 복구 모델 및 단순 복구 모델(백업이 실행 중인 경우 제외)에서 최소 로깅되는 작업을 식별합니다.This topic identifies the operations that are minimally logged under the bulk-logged recovery model (as well as under the simple recovery model, except when a backup is running).

참고

최소 로깅은 메모리 최적화 테이블에 대해 지원되지 않습니다.Minimal logging is not supported for memory-optimized tables.

참고

전체 복구 모델에서는 모든 대량 작업을 완전히 기록합니다.Under the full recovery model, all bulk operations are fully logged. 그러나 대량 작업에 대해 일시적으로 데이터베이스를 대량 로그 복구 모델로 전환하여 대량 작업 집합의 로깅을 최소화할 수 있습니다.However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations. 최소 로깅은 전체 로깅보다 효율적이며 대규모 대량 작업이 대량 트랜잭션 중에 사용 가능한 트랜잭션 로그 공간을 꽉 채울 가능성을 줄여줍니다.Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. 그러나 최소 로깅을 사용할 때 데이터베이스가 손상되거나 손실되면 데이터베이스를 오류 지점으로 복구할 수 없습니다.However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.

전체 복구 모델에서 전체 로깅되는 다음 작업은 단순 및 대량 로그 복구 모델에서 최소 로깅됩니다.The following operations, which are fully logged under the full recovery model, are minimally logged under the simple and bulk-logged recovery model:

트랜잭션 복제를 사용하는 경우 대량 로그 복구 모델에서도 BULK INSERT 작업이 모두 기록됩니다.When transactional replication is enabled, BULK INSERT operations are fully logged even under the Bulk Logged recovery model.

  • SELECT INTO 작업SELECT INTO operations.

트랜잭션 복제를 사용하는 경우 대량 로그 복구 모델에서도 SELECT INTO 작업이 모두 기록됩니다.When transactional replication is enabled, SELECT INTO operations are fully logged even under the Bulk Logged recovery model.

  • 새 데이터를 삽입 또는 추가할 때 UPDATE 문의 .WRITE 절을 사용하여 큰 값 데이터 형식을 부분적으로 업데이트하는 작업.Partial updates to large value data types, using the .WRITE clause in the UPDATE statement when inserting or appending new data. 기존 값이 업데이트되는 경우 최소 로깅이 사용되지 않습니다.Note that minimal logging is not used when existing values are updated. 큰 값 데이터 형식에 대한 자세한 내용은 데이터 형식(Transact-SQL)을 참조하세요.For more information about large value data types, see Data Types (Transact-SQL).

  • WRITETEXTUPDATETEXT 삽입 또는 새 데이터를 추가할 때 문은 텍스트, ntext이미지 데이터 형식 열입니다.WRITETEXT and UPDATETEXT statements when inserting or appending new data into the text, ntext, and image data type columns. 기존 값이 업데이트되는 경우 최소 로깅이 사용되지 않습니다.Note that minimal logging is not used when existing values are updated.

    중요

    WRITETEXT 및 UPDATETEXT 문은 더 이상 사용되지 않으므로새 응용 프로그램에서 사용하지 마세요.The WRITETEXT and UPDATETEXT statements are deprecated; avoid using them in new applications.

  • 데이터베이스가 단순 또는 대량 로그 복구 모델로 설정되면 작업이 오프라인으로 실행되든 온라인으로 실행되든 관계없이 일부 인덱스 DDL 작업이 최소 로깅됩니다.If the database is set to the simple or bulk-logged recovery model, some index DDL operations are minimally logged whether the operation is executed offline or online. 최소한으로 로깅되는 인덱스 작업은 다음과 같습니다.The minimally logged index operations are as follows:

    • CREATE INDEX 작업(인덱싱된 뷰 포함)CREATE INDEX operations (including indexed views).

    • ALTER INDEX REBUILD 또는 DBCC DBREINDEX 작업ALTER INDEX REBUILD or DBCC DBREINDEX operations.

      중요

      DBCC DBREINDEX 문더 이상 사용되지 않으므로 새 응용 프로그램에서 사용하지 마세요.The DBCC DBREINDEX statement is deprecated; Do not use it in new applications.

    • DROP INDEX 새 힙 다시 작성(해당 사항이 있을 경우)DROP INDEX new heap rebuild (if applicable). DROP INDEX 작업 중의 인덱스 페이지 할당 취소는 항상 모두 로깅됩니다.(Index page deallocation during a DROP INDEX operation is always fully logged.)

트랜잭션 로그 관리Managing the transaction log

자세한 정보!More information!

SQL Server 트랜잭션 로그 아키텍처 및 관리 가이드 SQL Server Transaction Log Architecture and Management Guide
트랜잭션 내구성 제어 Control Transaction Durability
대량 가져오기의 최소 로깅을 위한 필수 조건 Prerequisites for Minimal Logging in Bulk Import
SQL Server 데이터베이스 백업 및 복원 Back Up and Restore of SQL Server Databases
데이터베이스 검사점(SQL Server) Database Checkpoints (SQL Server)
데이터베이스의 속성 보기 또는 변경 View or Change the Properties of a Database
복구 모델(SQL Server)Recovery Models (SQL Server)