Một Nhật ký giao dịch phát triển bất ngờ hoặc trở nên đầy đủ trên máy tính đang chạy SQL Server

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:317375
TÓM TẮT
Trong SQL Server 7.0, trong SQL Server 2000 và trong SQL Server năm 2005, với các thiết lập autogrow, giao dịch đăng nhập tập tin mở có thể rộng tự động.

Thông thường, kích thước của tệp nhật ký giao dịch ổn định khi nó có thể chứa hết số lượng các giao dịch có thể xảy ra giữa giao dịch đăng nhập truncations rằng một trong hai trạm kiểm soát hoặc giao dịch đăng nhập Kích hoạt bản sao lưu.

Tuy nhiên, trong một số trường hợp đăng nhập giao dịch có thể trở nên rất lớn và chạy không gian hoặc trở nên đầy đủ. Thông thường, bạn nhận được thông báo lỗi sau khi một giao dịch đăng nhập tập tin sẽ đưa lên các có sẵn không gian đĩa và không thể mở rộng bất kỳ chi tiết:
Lỗi: 9002, Mức độ nghiêm trọng: 17, nhà nước: 2
Tệp sổ ghi cơ sở dữ liệu ' %. * ls' là đầy đủ.
Nếu bạn đang sử dụng SQL Server 2005, bạn nhận được một lỗi thông điệp mà là tương tự như sau:
Lỗi: 9002, mức độ nghiêm trọng: 17, Nhà nước: 2
Nhật ký giao dịch cho cơ sở dữ liệu ' %. * ls' là đầy đủ. Để tìm hiểu lý do tại sao không gian trong đăng nhập không thể tái sử dụng, xem log_reuse_wait_desc trong cột sys.Databases
Thêm vào thông báo lỗi này, SQL Server có thể đánh dấu cơ sở dữ liệu cho rằng vì của thiếu không gian cho giao dịch đăng nhập mở rộng. Cho thông tin thêm về làm thế nào để phục hồi từ tình trạng này, xem các "Không đủ dung lượng đĩa" chủ đề trong SQL Server sách trực tuyến.

Ngoài ra, giao dịch đăng nhập mở rộng có thể dẫn đến những trường hợp sau:
  • Một tệp sổ ghi của giao dịch rất lớn.
  • Các giao dịch có thể thất bại và có thể bắt đầu để quay trở lại.
  • Các giao dịch có thể mất một thời gian dài để hoàn thành.
  • Các vấn đề hiệu suất có thể xảy ra.
  • Chặn có thể xảy ra.

Nguyên nhân

Giao dịch đăng nhập mở rộng có thể xảy ra vì số sau đây lý do hay kịch bản: Chú ý Trong SQL Server 2005, bạn có thể xem lại các log_reuse_waitlog_reuse_wait_desc cột của sys.databases xem vào cửa hàng để xác định những điều sau đây:
  • Tại sao không gian Nhật ký giao dịch không tái sử dụng
  • Tại sao Nhật ký giao dịch không thể được cắt ngắn

Khoản giao dịch

Rõ ràng các giao dịch vẫn còn khoản nếu bạn không vấn đề một rõ ràng lệnh cam kết hoặc quay ngược lại. Phần lớn này thường xảy ra khi một ứng dụng các vấn đề hủy bỏ một hoặc một lệnh giao dịch SQL giết chết mà không có một tương ứng quay ngược lại lệnh. Hủy bỏ giao dịch xảy ra, nhưng nó không cuộn ngược; Vì vậy, SQL Server không thể truncate mỗi giao dịch đó xảy ra sau đó vì hủy bỏ giao dịch là vẫn mở. Bạn có thể sử dụng tham khảo DBCC OPENTRAN Transact-SQL để xác minh nếu không có đang hoạt động giao dịch trong cơ sở dữ liệu tại một thời điểm cụ thể. Để biết thêm về trường hợp cụ thể này, nhấp vào số bài viết sau để xem các bài viết trong cơ sở kiến thức Microsoft:
295108Chưa hoàn tất giao dịch có thể chứa số lượng lớn ổ khóa và trường hợp chặn
171224 Hiểu biết về cách thức hoạt động Transact-SQL KILL lệnh
Ngoài ra, xem các chủ đề "DBCC OPENTRAN" trong SQL Máy chủ sách trực tuyến.

Kịch bản đó có thể dẫn đến khoản giao dịch:
  • Một thiết kế ứng dụng giả định rằng tất cả các lỗi gây ra rollbacks.
  • Một thiết kế ứng dụng không hoàn toàn đưa vào tài khoản hành vi SQL Server khi nó cuộn lại để đặt tên các giao dịch hoặc đặc biệt lồng nhau được đặt tên theo các giao dịch. Nếu bạn cố gắng để quay trở lại một nội đặt tên là giao dịch, bạn nhận được thông báo lỗi sau:
    Máy chủ: Msg 6401, cấp 16, bang 1, dòng 13 không thể quay trở lại InnerTran. Không giao dịch hoặc savepoint của tên đó đã được tìm thấy.
    Sau khi SQL Server tạo ra các thông báo lỗi, nó tiếp tục các tuyên bố tiếp theo. Điều này là do thiết kế. Để biết thêm chi tiết, xem "Lồng nhau các giao dịch" hoặc "bên trong SQL Hệ phục vụ"chủ đề trong SQL Server sách trực tuyến.

    Microsoft khuyến cáo các sau khi bạn thiết kế ứng dụng của bạn:
    • Chỉ mở một giao dịch đơn vị (xem xét các khả năng rằng một tiến trình khác có thể gọi cho bạn).
    • Kiểm tra @@ TRANCOUNT trước khi bạn phát hành một cam kết, một Cuộn ngược trở về một, hoặc một tương tự như lệnh hoặc tuyên bố.
    • Viết mã của bạn với giả định rằng một @@ TRANCOUNT có thể "tổ" của bạn và kế hoạch cho các bên ngoài @@ TRANCOUNT để được cuộn sau khi một lỗi xảy ra.
    • Xem lại savepoint và đánh dấu tùy chọn cho các giao dịch. (Đây không phát hành ổ khóa!)
    • Thực hiện kiểm tra hoàn chỉnh.
  • Một ứng dụng cho phép người dùng tương tác bên trong các giao dịch. Điều này làm cho các giao dịch để vẫn mở cho một thời gian dài, mà nguyên nhân ngăn chặn và giao dịch đăng nhập tăng trưởng do không thể mở giao dịch được cắt ngắn và các giao dịch mới được bổ sung vào Nhật ký sau khi mở giao dịch.
  • Một ứng dụng mà không kiểm tra @@ TRANCOUNT để xác minh rằng không có không có giao dịch mở.
  • Mạng hoặc các lỗi khác đóng ứng dụng khách hàng kết nối đến máy chủ SQL mà không cần thông báo cho nó.
  • Kết nối tổng hợp. Sau khi nhân viên chủ đề được tạo ra, SQL Máy chủ reuses họ nếu họ không phục vụ một kết nối. Nếu kết nối người dùng bắt đầu từ một giao dịch và ngắt kết nối trước khi cam kết hoặc lăn trở lại các giao dịch, và một kết nối sau đó reuses cùng một sợi, trước đó giao dịch vẫn còn vẫn mở. Tình trạng này kết quả trong ổ khóa vẫn mở từ giao dịch trước đó và ngăn ngừa truncation của các cam kết các giao dịch trong Nhật ký, mà kết quả trong lớn đăng nhập kích thước tập tin.Để biết thêm thông tin về kết nối Tổng hợp, nhấp vào số bài viết sau đây để xem bài viết trong cơ sở kiến thức Microsoft:
    164221Làm thế nào để kích hoạt kết nối tổng hợp trong ứng dụng ODBC
back to the top

Các giao dịch rất lớn

Hồ sơ đăng nhập trong các tập tin log giao dịch được cắt ngắn trên một giao dịch bởi giao dịch cơ sở. Nếu phạm vi giao dịch lớn, mà giao dịch và các giao dịch bất kỳ bắt đầu sau khi nó không được gỡ bỏ từ các giao dịch đăng nhập trừ khi nó hoàn thành. Điều này có thể dẫn đến tập tin đăng nhập lớn. Nếu giao dịch là đủ lớn, tệp nhật ký có thể sử dụng không gian đĩa sẵn dùng và gây ra loại "giao dịch đăng nhập đầy đủ" thông báo lỗi như lỗi 9002. Để có thêm thông tin về những gì để làm gì khi bạn nhận được loại lỗi thông điệp được cung cấp trong phần "Thông tin thêm" bài viết này. Ngoài ra, phải mất rất nhiều thời gian và SQL Server trên cao để quay trở lại lớn các giao dịch.

back to the top

Hoạt động: DBCC DBREINDEX và tạo ra chỉ số

Vì các thay đổi trong mô hình phục hồi trong SQL Server 2000, khi bạn sử dụng chế độ Khôi phục đầy đủ và bạn chạy DBCC DBREINDEX, giao dịch đăng nhập có thể mở rộng đáng kể hơn so với SQL Server 7.0 trong một chế độ phục hồi tương đương với việc sử dụng của chọn vào hoặc BULK COPY và với "Trunc. Thoát trên chkpt.".

Mặc dù kích thước của các giao dịch đăng nhập sau khi chiến dịch DBREINDEX có thể là một vấn đề, cách tiếp cận này cung cấp tốt hơn Đăng Khôi phục hiệu suất.

back to the top

Trong khi khôi phục từ bản sao lưu đăng nhập giao dịch

Điều này được mô tả trong sau đây Microsoft Knowledge Base bài viết:
232196 Đăng nhập không gian sử dụng xuất hiện để phát triển sau khi khôi phục từ bản sao lưu

Nếu bạn đặt SQL Server 2000 để sử dụng với số lượng lớn đăng nhập chế độ và bạn phát hành một bản sao với số lượng lớn hoặc chọn thành tuyên bố, mỗi mức độ thay đổi đánh dấu và sau đó sao lưu khi bạn sao lưu các bản ghi của giao dịch. Mặc dù Điều này cho phép bạn sao lưu các bản ghi của giao dịch và phục hồi từ thất bại ngay cả sau khi bạn thực hiện với số lượng lớn các hoạt động, điều này thêm vào kích thước của giao dịch các bản ghi. SQL Server 7.0 không bao gồm các tính năng này. SQL Server 7.0 duy nhất ghi extents nào được thay đổi, nhưng nó không ghi lại extents thực tế. Vì vậy, ghi sổ chiếm không gian nhiều hơn một cách đáng kể trong SQL Server 2000 hơn trong SQL Server 7.0 trong chế độ số lượng lớn đăng nhập nhưng không nhiều như nó không đầy đủ chế độ.

back to the top

Các ứng dụng khách hàng không xử lý tất cả kết quả

Nếu bạn phát hành một truy vấn SQL Server và bạn không xử lý các kết quả ngay lập tức, bạn có thể được giữ ổ khóa và giảm concurrency ngày của bạn hệ phục vụ.

Ví dụ, giả sử bạn phát hành một truy vấn mà đòi hỏi hàng từ hai trang để cư trú của bạn thiết lập kết quả. SQL Server phân tích, biên dịch, và chạy truy vấn. Điều này có nghĩa rằng ổ khóa được chia sẻ được đặt trên hai trang đó chứa các hàng mà bạn phải có để đáp ứng các truy vấn của bạn. Ngoài ra, giả sử rằng không phải tất cả các hàng phù hợp lên một SQL Server TDS gói (phương pháp bởi» mà máy chủ liên lạc với khách hàng). TDS gói được điền và gửi cho khách hàng. Nếu tất cả các hàng từ trang đầu tiên phù hợp với gói TDS, SQL Máy chủ bản phát hành ổ khóa được chia sẻ trên trang đó nhưng lá một ổ khóa được chia sẻ trên các Thứ hai trang. SQL Server sau đó chờ đợi cho khách hàng để yêu cầu bộ dữ liệu (bạn có thể làm điều này bằng cách sử dụng DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults, hoặc FetchLast/FetchFirst ví dụ).

Điều này có nghĩa rằng các khóa được chia sẻ là tổ chức cho đến khi khách hàng yêu cầu phần còn lại của dữ liệu. Các quá trình đó yêu cầu dữ liệu từ trang thứ hai có thể bị chặn.

back to the top

Truy vấn thời gian ra trước khi một bản ghi của giao dịch đã hoàn tất các việc mở rộng và bạn nhận được các thông báo lỗi 'Đăng nhập đầy đủ' sai

Trong tình huống này, mặc dù không đủ không gian đĩa, bạn vẫn còn nhận một "ra khỏi không gian" lỗi thư.

Tình trạng này thay đổi cho SQL Server 7.0 và SQL Server 2000.

Một truy vấn có thể gây ra các giao dịch đăng nhập tự động mở rộng nếu đăng nhập giao dịch là gần như toàn bộ. Điều này có thể mất thêm thời gian, và một truy vấn có thể được ngừng lại hoặc có thể vượt quá gian chờ của nó khoảng thời gian do. SQL Server 7.0 trả về lỗi 9002 trong tình huống này. Vấn đề này không áp dụng cho SQL Server 2000.

Trong SQL Server 2000, nếu bạn có các tự động thu nhỏ tùy chọn bật đối với cơ sở dữ liệu, đó là một thời gian vô cùng nhỏ trong thời gian đó một Nhật ký giao dịch cố gắng tự động mở rộng, nhưng nó không thể bởi vì các tự động thu nhỏ chức năng đang chạy cùng một lúc. Cũng có thể làm sai sự kiện về lỗi 9002.

Thông thường, việc mở rộng tự động giao dịch đăng nhập tập tin xảy ra một cách nhanh chóng. Tuy nhiên, trong trường hợp sau, có thể mất lâu hơn thông thường:
  • Số gia tăng trưởng là quá nhỏ.
  • Máy chủ là chậm vì các lý do.
  • Ổ đĩa này không đủ nhanh.
back to the top

Các giao dịch unreplicated

Giao dịch đăng nhập kích thước của các nhà xuất bản cơ sở dữ liệu có thể mở rộng nếu bạn đang sử dụng nhân rộng. Các giao dịch đó ảnh hưởng đến các đối tượng được nhân rộng được đánh dấu là "Cho Replication." Các giao dịch, chẳng hạn như khoản giao dịch, không được xóa bỏ sau khi điểm kiểm tra hoặc sau khi bạn sao lưu đăng nhập giao dịch cho đến khi nhiệm vụ độc giả đăng nhập sao các giao dịch vào cơ sở dữ liệu phân phối và bỏ đánh dấu chúng. Nếu một vấn đề với nhiệm vụ trình đọc Nhật ký ngăn chặn nó từ đọc những giao dịch trong các nhà xuất bản cơ sở dữ liệu, kích thước của các bản ghi của giao dịch có thể tiếp tục mở rộng như số không nhân rộng các giao dịch tăng. Bạn có thể sử dụng DBCC OPENTRAN Transact-SQL tài liệu tham khảo để xác định lâu đời nhất không nhân rộng giao dịch.

Để biết thêm thông tin về xử lý sự cố unreplicated các giao dịch, xem các chủ đề "sp_replcounters" và "sp_repldone" trong SQL Server Sách trực tuyến.

Để biết thêm chi tiết, nhấp vào số bài viết sau để xem các bài viết trong cơ sở kiến thức Microsoft:
306769Khắc phục: Giao dịch đăng nhập cơ sở dữ liệu được xuất bản ảnh chụp không thể được cắt ngắn
240039 Khắc phục: DBCC OPENTRAN không báo cáo sao chép thông tin
198514 Khắc phục: Khôi phục sang mới gây ra các giao dịch ở lại trong đăng nhập
back to the top
THÔNG TIN THÊM
Nhật ký giao dịch cho bất kỳ cơ sở dữ liệu được quản lý như một tập hợp các ảo tập tin đăng nhập (VLFs) có kích thước SQL Server xác định nội bộ dựa trên Tổng Kích cỡ tệp sổ ghi và tăng tốc độ tăng trưởng trong sử dụng khi đăng nhập mở rộng. Một Nhật ký luôn luôn mở rộng trong các đơn vị của toàn bộ VLFs và nó chỉ có thể nén một ranh giới BOÅ. Một BOÅ có thể tồn tại ở một trong ba tiểu bang: hoạt động, RECOVERABLE, và tái sử dụng.
  • HOẠT ĐỘNG: Phần hoạt động của Nhật ký bắt đầu lúc trình tự đăng nhập tối thiểu số (LSN) đại diện cho một giao dịch (khoản) hoạt động. Các hoạt động phần của Nhật ký kết thúc ở cuối cùng viết LSN. Bất kỳ VLFs có chứa bất kỳ một phần các bản ghi hoạt động được xem là hoạt động VLFs. (không sử dụng không gian trong Nhật ký vật lý không phải là một phần của bất kỳ BOÅ.)
  • PHỤC HỒI: Phần của tệp nhật ký đến trước hoạt động lâu đời nhất giao dịch chỉ là cần thiết để duy trì một chuỗi các Nhật ký sao lưu cho mục đích phục hồi.
  • REUSABLE: Nếu bạn đang không duy trì giao dịch đăng nhập sao lưu, hoặc nếu bạn đã sao lưu các bản ghi, SQL Server reuses VLFs trước khi hoạt động lâu đời nhất giao dịch.
Khi SQL Server đạt tới kết thúc tệp nhật ký vật lý, nó bắt đầu sử dụng lại không gian trong tập tin vật lý bởi việc ban hành một xoay quanh quay chiến dịch bắt đầu của các tập tin. Trong thực tế, SQL Server tái chế các không gian trong tệp nhật ký không còn cần thiết cho việc phục hồi hoặc sao lưu mục đích. Nếu một trình tự sao lưu sổ ghi được duy bị trì, là một phần của Nhật ký trước khi tối thiểu LSN không thể được ghi đè cho đến khi bạn trở lại lên hoặc truncate những người đăng hồ sơ. Sau khi bạn thực hiện sao lưu đăng nhập, SQL Server có thể vòng tròn trở lại bắt đầu của tập tin. Sau khi SQL Server vòng tròn trở lại để bắt đầu viết hồ sơ đăng nhập trước đó trong tập tin đăng nhập, phần tái sử dụng các bản ghi là sau đó giữa cuối đăng nhập hợp lý và hoạt động phần các bản ghi.

Cho thông tin thêm, xem các chủ đề "Giao dịch đăng nhập vật lý kiến trúc" trong SQL Server sách trực tuyến. Ngoài ra, bạn có thể xem một biểu đồ tuyệt vời và thảo luận về điều này trên trang 190 của "Bên trong SQL Server 7.0" (Soukup, Ron. Bên trong Microsoft SQL Server 7.0, Microsoft Press, 1999), và cũng có trong các trang 182 thông qua 186 của "Bên trong SQL Server 2000" (Delaney, Kalen. Bên trong Microsoft SQL Server Năm 2000, Microsoft Press, 2000). Cơ sở dữ liệu SQL Server 7.0 và SQL Server 2000 có các tùy chọn để autogrow và autoshrink. Bạn có thể sử dụng các tùy chọn này để giúp bạn nén hoặc mở rộng log giao dịch của bạn.

Để biết thêm về cách các tùy chọn có thể ảnh hưởng đến máy chủ của bạn, nhấp vào số bài viết sau đây để xem bài viết trong cơ sở kiến thức Microsoft:
315512Cân nhắc cho cấu hình Autogrow và Autoshrink trong SQL Server
Một sự khác biệt giữa truncation so với nén các tập tin log giao dịch. Khi SQL Server truncates một tệp nhật ký giao dịch, điều này nghĩa là nội dung của tập tin đó (ví dụ, các giao dịch cam kết) sẽ bị xóa. Tuy nhiên, khi bạn đang xem kích thước tập tin từ một góc nhìn vũ trụ đĩa (ví dụ, trong Windows Explorer hoặc bằng cách sử dụng các DIR lệnh) kích thước vẫn không thay đổi. Tuy nhiên, không gian bên trong các tập tin .ldf bây giờ có thể được tái sử dụng các giao dịch mới. Chỉ khi SQL Server thu nhỏ kích thước của tệp nhật ký giao dịch, bạn có thực sự thấy một sự thay đổi trong Kích thước vật lý của các tập tin log.

Cho biết thêm thông tin về làm thế nào để thu nhỏ các bản ghi của giao dịch, nhấp vào số bài viết sau để xem các bài viết trong cơ sở kiến thức Microsoft:
256650Làm thế nào để thu nhỏ đăng nhập giao dịch SQL Server 7.0
272318 Thu hẹp lại trong SQL Server 2000 với DBCC SHRINKFILE giao dịch, đăng nhập
Để biết thêm thông tin về SQL Server 6,5 giao dịch đăng nhập việc sử dụng, nhấp vào số bài viết sau đây để xem bài viết trong cơ sở kiến thức Microsoft:
110139Nguyên nhân của SQL giao dịch đăng nhập làm đầy

Làm thế nào để xác định vị trí truy vấn mà tiêu thụ một lượng lớn không gian sổ ghi trong SQL Server 2005

Trong SQL Server 2005, bạn có thể sử dụng giao diện quản lý năng động sys.dm_tran_database_transactions (DMV) để định vị các truy vấn mà tiêu thụ một lượng lớn không gian đăng nhập. Các cột sau đây trong sys.dm_tran_database_transactions DMV có thể hữu dụng:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
Bạn có thể truy vấn các cột sql_handle của sys.dm_exec_requests DMV để có được văn bản thực tế tuyên bố rằng tiêu thụ một lượng lớn không gian đăng nhập. Bạn có thể làm điều này bằng cách tham gia sys.dm_tran_database_transactions DMV và sys.dm_tran_session_transactions DMV trên cột transaction_id, và sau đó thêm một tham gia bổ sung với sys.dm_exec_requests trên cột session_id.

Để biết thêm chi tiết về sys.dm_tran_database_transactions DMV, ghé thăm Web site sau của Microsoft Developer Network (MSDN): Để biết thêm chi tiết về sys.dm_tran_session_transactions DMV, truy cập vào MSDN Web site sau: Để biết thêm chi tiết về sys.dm_exec_requests DMV, truy cập vào MSDN Web site sau:

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 317375 - Xem lại Lần cuối: 09/17/2011 23:48:00 - Bản sửa đổi: 3.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition

  • kbsqlsetup kbinfo kbmt KB317375 KbMtvi
Phản hồi