DBCC Loginfo
DBCC log (' Qssys ', type=2)
Go
SELECT * from Sys.fn_dblog (null,null)
Select [Dirty pages],[minimum lsn],[checkpoint end],[chkpt Begin DB version],[checkpoint begin],operation,context,[log Record length],allocunitname from Fn_dblog (null,null)
SELECT * FROM dbo. T_companyaccount with (NOLOCK)
Operation: Operations done by the current LSN
CURRENTLSN: Serial number uniquely identified in the transaction log
Context: Action contexts
TransactionID: Transaction ID
Log Record fixed length:lsn length of the virtual log file of the station
Previous LSN: Previous LSN number
Allocuntilid: The unit ID assigned to the data being modified
Allocuntilname: The name of the modified data table
Page id:0001:00000121 converted to decimal: 289 so view PageID for 289 DBCC PAGE ([pratice],1,289,3)
SlotID: The first few records on the data page where the data resides
PartitionID: The partition ID of the data page where the data resides
[Checkpoint begin]: Start time
[chkpt Begin DB version]:sql SERVER version sql Srver 2005,2008,2012:611,661,706
[Checkpoint end]: End time
[Minimum LSN]: The sequence number (LSN) of this first log record is called the minimum Recovery sequence number (min LSN)
[Dirty pages]: Dirty data page
Oldest replicated Begin LSN: The oldest replication start LSN if the database configuration is replicated
Next replicated End LSN: Next replication End LSN
Last distributed end LSN: Latest distribution End LSN
SPID: Process ID to perform the current operation
Beginlog Status: Start logging the state of the transaction log, which indicates that the transaction log is now logged properly
Begin Time: Transaction start
Transaction Name: Transaction name
End Time: Transaction end
Transaction begin: Records the cureent LSN of the begin Transaction of this transaction
Master DBID: Displays the DBID of the current master database
Preplog Begin LSN: The previous transaction log LSN before starting the database
Prepare time: Ready to start the database
New Split page: Which data page generated the page split
Rows Deleted: How many rows of data pages have been deleted
Description: Describes what this transaction does, and sometimes the name of the transaction is not necessarily the name of the operation.
For example, it happens that the transaction name and description are all create TABLE if you name the transaction, then you can only see the description column to see what the transaction is.
Operation |
Context |
Explain |
Lop_set_bits |
Lcx_diff_map |
Set Bitmap, Data: Differential (differential) Backup: Only after the last full backup is backed up, make the modified portion. The backup unit is a zone (Extent). means that even if only one page has been changed in a zone, it will be reflected in the differential backup. Differential backups depend on a bitmap for maintenance, a bit corresponds to a zone, and since the last full backup, the modified area is set to 1, while the corresponding zone in bitmap is backed up by a differential backup. After the next full backup, all the bits in bitmap will be reset to 0 and this bitmap in the database page 7th: DCM page Variance Change (DIFFERENTIALCHANGEDMAP,DCM) Page he tracks which area of a file has been modified since the latest full database backup. SQL Server uses incremental backups only to incrementally back up partitions that have changed data |
Lop_begin_xact |
|
Transaction start |
Lop_modify_row |
Lcx_heap |
Modify a row of records in a heap table |
Lop_prep_xact |
|
Prepare to start the database |
Lop_commit_xact |
|
Commit a transaction |
Lop_modify_row |
Lcx_boot_page |
Modify the Database startup page |
Lop_modify_header |
Lcx_pfs |
Modify page header information for a PFS page |
Lop_insert_rows |
Lcx_clustered |
Insert data to index page of clustered index |
Lop_insert_rows |
Lcx_index_leaf |
The leaf node that inserts data into the index is the data page |
Lop_format_page |
Lcx_clustered |
Reorganize clustered Indexes |
Lop_delete_split |
Lcx_clustered |
Deleting a row of records from a clustered Index table causes page splits |
Lop_modify_header |
Lcx_heap |
To modify the header information for a page of a heap table |
Lop_begin_ckpt |
Lcx_null |
Check Point start |
Lop_end_ckpt |
Lcx_null |
Check Point end |
Lop_set_free_space |
Lcx_pfs |
Modify the PFS page settings that data page is free |
Lop_root_change |
Lcx_clustered |
Root node change of clustered index |
Lop_insert_rows |
Lcx_heap |
Inserting data into the heap table |
lop_ Format_page |
lcx_heap |
data page in format heap |
Operation |
Lock Information |
Explain |
Lop_lock_xact |
HoBt 0:acquire_lock_sch_m metadata:database_id = STATS (object_id = 7, stats_id = 11) |
Acquire a lock in a transaction |
Under the bulk-logged recovery model, you will not see the operation of the data page in the transaction log record, when you use bcp, bulk inert, select into bulk operation statement
Modify the data and insert the data as you can not find it in the transaction log records.
So when the bulk-logged recovery model, the LDF file is so small, the insertion speed is so fast
The following references MSDN:
http://msdn.microsoft.com/zh-cn/library/ms190925.aspxOperations that minimize log volume "Minimal Logging" means only the information required to recover a transaction in the event of a point-in-time recovery is not supported. This topic describes actions that are minimally logged under the bulk-logged recovery model (and under the simple Recovery model), but that are exceptions when you run a backup.NoteUnder the full recovery model, all bulk operations are fully documented. However, you can minimize the logging of a set of bulk operations by temporarily switching the database to the bulk-logged recovery model for bulk operations. Minimal logging is more efficient than full logging and reduces the likelihood of large-scale bulk operations filling up the available transaction log space during bulk transactions. However, you cannot recover a database to a point of failure if the database is damaged or lost when minimal logging is in effect. The following operations perform full logging under the full recovery model, while minimally logged under the simple and bulk-logged Recovery model: Bulk Import operations (bcp, BULK Insert, and insert ... SELECT). For more information about when to minimally record a bulk import table, see prerequisites for minimally logging in bulk import. NoteWhen transactional replication is enabled, the BULK INSERT operation is fully logged, even under the bulk-logged recovery model. SELECT into operation.NoteWhen transactional replication is enabled, the SELECT into operation is fully logged, even under the bulk-logged recovery model. When inserting or appending new data, use the in the UPDATE statement. The WRITE clause is partially updated to the large value data type. Note that minimal logging is not used when updating existing values. For more information about large value data types, see Data types (Transact-SQL). WRITETEXT and UPDATETEXT statements when new data is inserted or appended in the text, ntext, and image data type columns. Note that minimal logging is not used when updating existing values.NoteThe use of WRITETEXT and UPDATETEXT statements is deprecated, so you should avoid using them in new applications. If the database is set to a simple or bulk-logged recovery model, some index DDL operations are minimally logged, whether the operation is performed offline or online. The index operations that are minimally logged are as follows: CREATE index operation (including indexed views). ALTER INDEX REBUILD or DBCC dbreindex operation.NoteThe DBCC Dbreindex statement is not recommended, so you should avoid using the statement in a new application. DROP INDEX New Heap regeneration (if applicable).NoteThe release of the index page is always fully logged during the DROP index operation.
You can also take a look at this post about the bulk-logged recovery model
http://social.msdn.microsoft.com/Forums/zh-CN/958febc2-5eaf-46e4-b658-4bea087c0b0f
SQL Server Log