Làm Sao Giảm Bớt Dung Lượng File LOG Của SQL Server

Guess Post: Vũ Minh Tâm

Vào một ngày đẹp trời, bạn nhận thấy rằng file LOG của mình quá lớn, chiếm gần hết ổ cứng và không thể thực hiện bất kì một thao tác nào trên dữ liệu.
Hay bạn thấy, trong khi dữ liệu của mình chỉ có vài GB, mà file LOG lên đến tận hàng trăm GB.
Phải làm thế nào ?

Có rất nhiều cách để giải quyết vấn đề này

- Detach DB, xóa file LOG, sau đấy ATTACH lại DB
Tuy nhiên với CSDL đòi hỏi tính sẵn sàng cao, thì ko mấy ai cho phép bạn làm điều này.

- Backup LOG với OpTION là TRUNCATE_ONLY hoặc NO_LOG
Với phiên bản SQL Server 2008 thì đã bỏ Option này

SQL Server 2005 Books Online:

“[TRUNCATE_ONLY]

This option will be removed in a future version of SQL Server. Avoid using it in new development work, and plan to modify applications that currently use it.

We recommend that you never use NO_LOG or TRUNCATE_ONLY to manually truncate the transaction log…”.

Tôi thường dùng cách thứ 3.

Giả sử DB của tôi là Test.

File Data : Test_Data.MDF
File Log  : Test_Log.LDF

USE Test;
GO
 
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE Test
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (Test_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE Test
SET RECOVERY FULL;
GO

Giải thích

- Có 3 chế độ Recovery trong SQL Server , FULL, SIMPLE và BULK LOGGED

Chế độ mặc định là FULL.
Bạn có thể vào phần Option của DB, xem trong Recovery Model.

Khi ở chế độ này,  bất kì một transaction nào, kể cả khi đã commit cũng đều được lưu trong LOG, do đó có thể dựa vào những transaction này để “quay lui (rollback)” DB về bất kì thời điểm nào. Vì thế với những DB có Transaction nhiều, DATA ít thì file LOG vẫn có thể rất lớn.

- Đầu tiên SET RECOVERY của DB về SIMPLE, ở chế độ này, sau khi transaction được COMMIT, sẽ tự động xóa. Do vậy File LOG của DB ở chế độ này thường rất nhỏ.

- Dùng DBCC SHRINKFILE để SHRINK file log xuống còn 1 Mb
Nếu không set Recovery về SIMPLE, thì sẽ ko thể xóa bỏ hết các transaction đã được COMMIT.
SHRINKFILE chỉ thu dọn và sắp xếp  và phân bố lại dữ liệu, bỏ các vùng trống để giải phóng bộ nhớ, chứ không phải xóa dữ liệu. Vì thế ở chế độ FULL, SHRINKFILE hầu như ko tác dụng, hoặc nếu có thì file LOG dung lượng giảm đi ko đáng kể.

- Sau đó SET RECOVERY về lại FULL

Trên MSDN cũng khuyên nếu muốn Backup LOG, các bạn nên chuyển về chế độ SIMPLE, hơn là backup LOG với Truncate_Only và No_LOG

* Chú ý: Với những DB lớn, có kế hoạch Backup riêng, bạn cần hỏi ý kiến của DBA trước khi thực hiện. Vì một vài chế độ BackUp dựa rất nhiều vào file LOG.

Tuy nhiên nếu có DBA, thì không bao giờ để xảy ra trường hợp này, vì công việc của họ là thường xuyên theo dõi, giám sát và xử lý  để Server hoạt động tốt.




Tags: , ,

51 Comments
Posted on 16/11/2010 | Categories: Database Administration

Các bài viết tương tự

Comments
  • Vũ Tuấn Anh (03/12/2010 8:17 pm)

    - Bài viết này quá hay với những gì tôi mới được biết về MSSQL, mong mọi người trong nghề DBA đóng góp để bọn em có cái học và tham khảo.

    Cám ơn vì đã có bài viết hay như vậy!

  • Phihn (26/01/2011 12:13 am)

    CSDL mình đang bị tình trạng là báo lỗi deadlock liên tục. Mình không biết trao đổi với bạn chổ nào. Mạn phép gõ comment giúp đỡ ở đây. Có cách nào để xử lý tình trạng bị deadlock không. CSDL của mình dùng từ năm 2005, và bị tình trạng deadlock chỉ từ tháng 1/2011. Và chỉ bị báo lỗi deadlock ở 1 phân hệ là cập nhật chỉ số, các phân hệ khác vẫn hoạt động tốt. Mong bạn giúp đỡ mình tìm ra lỗi. Cảm ơn bạn.

  • Kiet (12/04/2011 7:39 pm)

    Cơ sở dữ liệu của tôi bị lổi hiện tại chỉ còn một file .mdf khoản 78GB, tôi chọn attach với lệnh sp_attach_single_file_db nhưng không thành công hướng dẫn thêm cho tôi về vấn đề này.

  • Red Devilic (13/04/2011 6:39 pm)

    @Phihn: Vấn đề xử lý Deadlock cũng không đơn giản. Có thể tại phân hệ cập nhật chỉ số, số lượng thao tác cập nhật dữ liệu ở phần này là lớn, nhiều user sử dụng. Và cách xử lý trên phân hệ này không được tốt, ( sử dụng CURSOR, transaction, thao tác phức tạp và mất nhiều thời gian), …. nên dẫn đến việc xuất hiện lock.

    Bạn có thể gửi câu truy vấn lên đây, và mô tả qua 1 chút về các bảng liên quan đến câu truy vấn để mình có thể hướng dẫn cụ thể hơn.

    @Kiet: Bạn có thể mô tả rõ hơn về lỗi bạn gặp phải ?

    Bạn có thể attach DB bình thường, không cần file log bằng cách khi chọn file MDF để attach, remove phần chọn file LOG (Ldf) và tiến hành attach lại bình thường. File MdF của bạn khá lớn, có thể bạn cần nghiên cứu qua File Group để quản lý dễ dàng hơn.

    • trungnt (03/05/2014 2:40 am)

      không fai lúc nào cũng Remove file Log mà Add dc, có nhưng trường hợp mất file Log thì bó tay không attach file dc . :(

  • Kiet (14/04/2011 10:28 pm)

    Hi Red Devilic

    mình không thể attach DB bình thường, và làm theo cách là remove phần log đi nhưng vẫn không thể nào attach được, khi attach xuất hiện lỗi :

    TITLE: Microsoft SQL Server Management Studio

    ——————————

    Attach database failed for Server 'SRUNI1'. (Microsoft.SqlServer.Smo)

    For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft...

    ——————————

    ADDITIONAL INFORMATION:

    An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

    ——————————

    The operating system returned error 38(Reached the end of the file.) to SQL Server during a read at offset 0x00001ea05c0000 in file 'D:DBSQLWSS_Content_log.LDF'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

    Operating system error 38(Reached the end of the file.) on file "D:DBSQLWSS_Content_log.LDF" during ReadFileHdr.

    Could not open new database 'WSS_Content'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 823)

    For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft...

    ——————————

    BUTTONS:

    OK

    ——————————

  • Lola (14/04/2011 11:23 pm)

    Cảm ơn bạn vì bài viết hay nhưng đọc xong mình vẫn còn vướng mắc một vài chỗ mong bạn giải thích thêm hộ mình:

    1. Ở bước

    "…

    SET RECOVERY SIMPLE;

    …"

    như mình đọc khi để ở chế độ simple thì tất cả các transaction sau khi COMMIT sẽ bị xóa hết vậy thì sau này mình muốn rollback nó về thời điểm trước đó thì ko được nữa đúng không? bạn có option nào vẫn để chê độ simple nhưng giữ được các file log của DB trước đó 1 tuần không? vì 1 DBA thì không thể xóa hết log file của mình được

    2.

    "…

    GO

    – Shrink the truncated log file to 1 MB.

    DBCC SHRINKFILE (Test_Log, 1);

    …"

    Bạn có thể nói rõ hơn về câu lệnh " Shrink the truncated log file to 1 MB" này không? theo như giải thích của bạn ở trên thì mình vẫn chưa hiểu rõ cho lắm.

    Mong nhận được lời giải thích của bạn. Tks

  • Red Devilic (15/04/2011 8:39 pm)

    @Lola:

    1- Bạn có thể backup Full database trước khi thực hiện các bước trong bài viết này. NHư vậy nếu có vấn đề gì xảy ra cần rollback dữ liệu thì có thể thực hiện với file backup trước đó. NGoài ra trong web này có nhiều bài viết của anh Vũ Huy Tâm về các phương pháp backup và restore dữ liệu, bạn có thể tham khảo thêm.

    Quan trọng nhất là Backup Plan của bạn như thế nào, sử dụng Backup Transaction hay Diffirential Backup, v.v… Ở đây mình hướng dẫn cho đại đa số các bạn, thường để RECOVERY là FULL và không để ý nhiều đến file LOG. Khi gặp trường hợp này, bài viết trên sẽ có tác dụng lớn, giúp bạn giải quyết được vấn đề trước mắt, sau đó có thể tìm hiểu và xây dựng các phương pháp backup khác để chủ động hơn trong việc quản lý backup và recover DB khi có sự cố

    2- Về cấu trúc của câu lệnh trên, chắc bạn cũng không có thắc mắc gì. Mình chỉ giải đáp vì sao có thể SHRINK xuống 1 MB được

    Nếu bạn để RECOVERY là FULL, có nghĩa là các transaction của bạn đều được lưu đầy đủ và bạn có thể rollback data về bất kì thời điểm nào.

    Như vậy dù bạn SHRINK xuống 1 MB hay 2 MB đều không thể được, mà file LOG chỉ giảm xuông đc 1 mức cụ thể nào đó, đảm bảo cho việc rollback dữ liệu của bạn vẫn thực hiện được.

    Bạn có thể hiểu đơn giản như việc phân mảnh ổ cứng, dù bạn có dọn dẹp, phân mảnh lại ổ cứng hay compressed data thì ổ cứng của bạn cũng không thể giải phóng được 100% dung lượng, vì data của bạn không mất đi, chỉ dọn dẹp, nén lại cho tiết kiệm không gian hơn mà thôi.

    Khi bạn đã chỉnh chế độ về SIMPLE, tức là các transaction đã lưu trong LOG không còn giá trị nữa, bạn có thể xóa đi thoải mái, tương tự như dữ liệu trên đĩa của bạn không cần thiết, bạn có thể format lại ổ đĩa :)

  • Lola (16/04/2011 2:43 am)

    Cảm ơn bạn rất nhiều! mình đã hiểu và cũng đã test thử thấy rất ok :d

  • daviben (02/08/2011 7:00 am)

    Xin chào,

    Minh tìm hiểu thì thấy có ý kiến cho ràng Shrink database file sẽ gây ra hiện tượng Fragmentation.Điều này có đúng không và nó có ảnh hưởng gì đến performance của hệ thống không?

    • Red Devilic (02/08/2011 8:19 am)

      Hi bạn

      Điều bạn nói là đúng. Shrink Database quá nhiều sẽ dẫn đến hiện tượng Fragmentation.
      Và dĩ nhiên là một hệ thống có Fragmentation cao thì sẽ ảnh hưởng đến performance.

      Trong khuôn khổ bài viết ở trên là SHRINK file log, điều này ko ảnh hưởng đến hệ thống của bạn.
      Nếu bạn có nhu cầu chi tiết hơn về SHRINK database thì có thể post vào phần Trang Hỏi Đáp.

      • daviben (02/08/2011 9:31 pm)

        Hiên tại database server của minh dùng SQL server 2008, trong đó Log file rất lớn.Mình đã nghĩ đến việc thường xuyên full Backup LOG với OpTION là TRUNCATE_ONLY hoặc NO_LOG để không cho file log lớn thêm.Việc này có thể tác dụng không và trong SQL 2008 có các option trên không?
        Mình chưa làm trên SQL 2008 bao giờ.Bạn chỉ dẫn giúp nhé.

  • Vu Tuan Anh (27/12/2011 10:46 pm)

    - Em gặp một vấn đề về theo dõi perfomace của MSSQL 2005.
    + Khi em remote desktop tới server chạy MSSQL 2005 check CPU, Memory thì thông số rất cao, Memory chạy service mssql thường lên tới 98, 99%.
    + Nhưng khi lên trực tiếp cắm màn hình vào server cài DB MSSQL 2005 đó check trực tiếp thì ngược lại hoàn thoàn. Nó chỉ chiếm 40,50% Memory cho service MSSQL Server.

    Mong các anh chỉ dẫn giúp làm thế nào có thể biết được chính xác mức độ memory của hệ thống chạy service MSSQL 2005 khi remote desktop quản trị.

    Lý do sự khác nhau đó là gì ạ? Em cũng tham khảo trên mạng mà chưa tìm được lới giải thích nào cụ thể.

    Mong mọi người chỉ giúp.

  • Nga (12/03/2012 12:03 am)
    USE Test;
    GO
     
    -- Truncate the log by changing the database recovery model to SIMPLE.
    ALTER DATABASE Test
    SET RECOVERY SIMPLE;
    GO
    -- Shrink the truncated log file to 1 MB.
    DBCC SHRINKFILE (Test_Log, 1);
    GO
    -- Reset the database recovery model.
    ALTER DATABASE Test
    SET RECOVERY FULL;
    GO

    Em làm theo hướng dẫn như trên mà khi chạy nó báo lỗi Could not locate file ‘DB_log’ for database ‘DB’. Xin các bác chỉ giúp em sửa lỗi này.

    Cám ơn

  • DungNx (13/03/2012 4:54 am)

    USE Test; đó lỗi của bạn đó
    trong Sql của bạn đâu có Database tên : Test đâu

    • Nga (13/03/2012 6:14 am)

      Uh, mình biết mình chỉ đưa đoạn code đó lên để mọi người biết là mình dùng cách này để giảm file log. Nhưng sao khi chạy thì bị báo lỗi Could not locate file ‘DB_log’ for database ‘DB’, trong khi mình đã thay database Test thành DB là tên datbase của mình.

      • Vũ Huy Tâm (13/03/2012 7:36 am)

        Chắc tên log file của database đó không phải như vậy. Bạn chạy thủ tục sau nó sẽ cho bạn biết tên của log file: sp_helpfile

        • Nga (13/03/2012 10:56 pm)

          Cám ơn bác Tâm nhiều.

        • Nga (13/03/2012 11:00 pm)

          Mà bác Tâm cho em hỏi, tại sao tên database là DB mà khi vào properties của database đó logicalname lại là DB_NEW, mình sửa logicalname thành DB có ảnh hưởng gì đến database ko?

          • nguyen cuong (19/04/2012 6:03 am)

            Ban nen doi ten DB_NEW thanh DB thi se thanh cong

            Chac la do khi ban Restore Database da tao csdl ten la DB_new.

  • Phúc Minh (06/08/2012 11:19 pm)

    mình dùng sql 2000, file log giwof lớn quá, mình làm như hướng dẫn mà không giảm bớt, vào lệnh shrink database/ file/ chọn file log thì nó giới hạn dung lượng giảm xuống (mấy chục GB) mình phải làm sao?

    • Vũ Huy Tâm (07/08/2012 3:33 pm)

      Nếu database đang để ở full recovery mode thì bạn không shrink được bao nhiêu, như trong bài viết đã nói. Bạn kiểm tra xem đã có bước chuyển recovery mode thành simple chưa.

    • Ayelen (04/07/2015 3:04 pm)

      I’m so glad I found my solituon online.

  • Tam Truong (05/10/2012 4:07 am)

    Gui các anh chị
    Cho em hỏi có cách chuyển đổi nào từ file .lfd sang file .mdf không ?
    Đừng chê câu hỏi này hơi ngớ ngẫn nhe!
    Vì có một số anh chị và quản trị họ nói sẽ làm được..em muốn hiểu thêm chút nữa về phương thức chuyển đổi này ?
    Chứ em học và tìm hiểu thì chưa thấy cách chuyển đổi đó…!
    Thanks!

  • Tam Truong (05/10/2012 4:12 am)

    viết nhầm”chuyển đổi từ file .LDF sang file .MDF”

    • Vũ Huy Tâm (05/10/2012 9:40 am)

      không hiểu bạn nói chuyển đổi theo nghĩa nào? ldf là file log chỉ chứa các giao dịch dữ liệu, còn mdf mới thực chứa dữ liệu, giữa chúng không có gì tương đồng để chuyển đổi cho nhau cả

      • Tam Truong (08/10/2012 5:34 am)

        Em cũng tìm hiểu và thấy nó không tương đồng..em đã có câu trả lời cho người mà đưa ra tin này rồi.
        Cảm ơn anh Huy Tâm nhiều!

      • Rulertimes (09/10/2012 10:45 pm)

        Tức là khi hỏng file MDF mà muốn khôi phục lại dữ liệu từ file .LDF thì làm như thế nào? Mình cũng có nghe ý kiến như vậy mà chưa biết cách làm, Xin cảm ơn trước!

  • Le Sanh (02/11/2012 8:11 pm)

    Làm sao để biết được cở sở dữ liệu của mình đã thêm, xóa sửa những gì thông qua log file. Mình thử vào sever name -> Management-> SQL server Logs để xem thử nhưng không thấy, toàn lấy log in faild chứ ko thấy các log của dữ liệu mình thêm vào?

    • Vũ Huy Tâm (05/11/2012 12:36 pm)

      cái SQL Server logs đó chỉ audit các access vào database và mặc định là chỉ audit cho login failure. Để theo dõi các thay đổi dữ liệu bạn cần dùng Change Data Capture.

  • Hang Tran (06/11/2012 12:21 am)

    Hi anh Tâm
    anh Tâm có thể cho em xin email để tiện trao đổi được không a? Em có một số vấn đề thắc mắc muốn nhờ anh giúp đỡ. Cảm ơn anh

  • Omni Nguyen (26/03/2013 10:23 pm)

    Anh Tâm cho em hỏi chút là: trường hợp đổi về simple mode và shrink thì log đó sẽ bị mất, không khôi phục được nữa đúng không anh?
    Nếu em muốn backup log ra, rồi shrink, rồi sau đó nếu lỗi thì vẫn dùng log backup đó để khôi phục thì không được ah anh?
    Như trường hợp của anh nói thì sau khi đổi về recovery mode là FULL thì phải làm 1 bản backup full luôn để tránh trường hợp DB lỗi thì vẫn có cái để khôi phục. đúng không anh?
    Em cảm ơn anh ạ

  • Vũ Huy Tâm (28/03/2013 9:49 am)

    Đúng rồi, sau khi shrink thì log file đã bị truncate và không còn chứa gì nữa. Nhưng trước đó nếu bạn đã thực hiện backup thì bạn có thể luôn luôn restore lại khi cần.
    Sau khi đổi lại recovery mode thành FULL thì cần thực hiện full backup luôn vì đây là bản full backup đầu tiên để các backup khác (transaction log và differential backup) dựa vào.

  • Minh Đức (15/04/2013 10:16 pm)

    Anh Tâm có thể cho em hỏi: hiện giờ em có file backup Full khoảng 700M (với file log nếu phục hồi là hơn 9G). Em định phục hồi vào máy laptop để check thì nó báo không đủ dung lương (máy còn >2G). Vậy có cách nào phục hồi file này không anh?
    Giống câu hỏi bạn ở trên em muốn hỏi sau khi làm bản backup full đầu tiên sau khi shrink thì có còn phục hồi được dữ liệu từ bản full trước khi shrink không ạ?

    • Minh Đức (16/04/2013 4:34 am)

      Em có shrink nhưng không được, em bấm “!” xong nó vèo 1 cái chạy xong và dung lượng file k0 thay đổi. nó chạy như kiểu bị lỗi ý nên chạy và tự thoát hay sao ý. em dùng sql2005

  • Vũ Huy Tâm (18/04/2013 10:30 am)

    @Minh Đức: Nếu logfile lớn như vậy thì chắc chắn không vừa vào laptop của bạn. Hơn nữa khi restore nó cần 1 không gian tạm bằng khoảng kích thước của database để dùng tạm trong quá trình restore. Bạn cần shrink log trước rồi mới backup. Bạn làm như hướng dẫn trong bài chưa?
    - chuyển recovery model về simple
    - truncate log
    - chuyển recovery model lại về full

    “sau khi làm bản backup full đầu tiên sau khi shrink thì có còn phục hồi được dữ liệu từ bản full trước khi shrink không ạ?”
    Khi có bạn full backup trong tay thì bạn luôn có thể restore lại, không phụ thuộc vào cấu hình của database hiện tại

  • tung (18/03/2014 7:13 am)

    Bác tâm cho em hỏi chút , khi em dùng cách của bài viết để giảm dung lượng file log xuống . Và em có thực hiện backup full định kỳ vào 4h sáng . Nghĩa là em thực hiện giảm file log theo bài viết này trước đó 1 tuần rồi .

    Hôm nay database của em có vấn đề và em làm theo bài viết: http://www.sqlviet.com/blog/lay-lai-du-lieu-sau-khi-xoa . để rollback lại data thì nhận được thông báo lỗi : “Msg 4214, Level 16, State 1, Line 1
    BACKUP LOG cannot be performed because there is no current database backup.
    Msg 3013, Level 16, State 1, Line 1
    BACKUP LOG is terminating abnormally.

    - Bác cho em hỏi là làm thế thì nó sẽ không rollback lại được nữa ạ ? Có cách nào để rollback lại dữ liệu hay không ?

    • Vũ Huy Tâm (19/03/2014 2:28 pm)

      Bác cần phải restore full từ bản full backup trước. Nhớ là các log backup chỉ backup các trans log kể từ lần full backup gần đây nhất. Bác nêu trình tự các bước bác đã làm có thể sẽ làm rõ hơn nguyên nhân

      • tung (19/03/2014 10:42 pm)

        Vâng để em nêu vắn tắt trình tự bác xem sai chỗ nào chỉ em ạ :

        - Vào ngày 10/3/2014 em thực hiện giảm dung lượng file log như bài viết này.

        - Em có thiết lập 1 job backup database định kỳ vào 4h sáng hàng ngày.

        - Ví dụ thời điểm em phát hiện ra lỗi vào 14h ngày hôm nay. Em thực hiện lệnh sau thì báo lỗi :

          BACKUP LOG TestDB TO DISK = 'D:\backup\TestDB.trn' WITH INIT
        Msg 4214, LEVEL 16, STATE 1, Line 1
        BACKUP LOG cannot be performed because there IS NO CURRENT DATABASE BACKUP.
        Msg 3013, LEVEL 16, STATE 1, Line 1
        BACKUP LOG IS terminating abnormally.

        – Em test lại với data khác nếu không thực hiện việc giảm dung lượng file log thì vẫn được ạ ! Mong hồi âm của bác !

  • Red Devilic (24/03/2014 10:43 pm)

    Bạn tham khảo thêm link và giải quyết theo hướng đó nhé:

    http://blog.sqlauthority.com/2012/12/24/sql-server-fix-error-4214-backup-log-cannot-be-performed-because-there-is-no-current-database-backup-2/

    Bài này viết đã lâu nên không update, lúc đó mình hướng đến việc giải quyết tức thời + ưu tiên cho những hệ thống không chú trọng đến việc rollback dât.

    • tung (25/03/2014 11:31 pm)

      Vâng . Cảm ơn bác đã góp ý, em đọc bài viết trên thì thấy nó bảo khi chuyển từ simple sang full thì không tạo backup tran được mà phải tạo 1 bản full backup rồi restore lại thì mới có thể sử dụng backup tran phải không bác ? Em sẽ thử xem sao ạ!

  • Xuân Đạo (26/03/2014 3:21 am)

    chao dien dan.
    Em bị xóa nhầm dữ liệu, khi phục hồi lại em attach vào database thì báo lỗi 5171. vậy có cách nào để attach vào được không mọi người. em đang dùng SQL 2005.
    mong được mọi người chỉ cách cho em. cần gấp và quan trọng lắm

    • Vũ Huy Tâm (26/03/2014 10:35 am)

      Nếu bạn restore thì cần dùng file backup. Nếu attach thì mới dùng data file (mdf). Mình đoán bạn đang cần restore lại bản cũ để lấy lại dữ liệu bị xóa nhầm, nếu vậy bạn cần restore từ file backup, ko phải mdf file

      • Xuân Đạo (26/03/2014 10:09 pm)

        Chào bạn, nhưng mình không có file backup, vì mình không backup nên không thể restore. mình có tải mấy chương trình sửa lỗi về, nhưng không lưu lại được, vì chỉ là bản demo thôi. xin hỏi ai có những chương trình đó mà có crack thì chỉ mình với. xin cảm ơn

  • Johnb19 (30/06/2014 2:56 pm)

    Some truly select blog posts on this web site , saved to fav. bdadedbdkdge

  • Nguyễn Phương Tâm (07/08/2016 10:01 pm)

    Chào mọi người, em cần tư vấn về vấn đề này, hiện tại thì DB của công ty em là 35GB BAK (chạy vào 22h tối mỗi ngày), 1 tháng gần đây sever thường xuyên bị chậm, thì e vào sever stop and start lại thì hết liền nhưng tần xuất ngày càng nhiêu, hiện thời thì 1 ngày em phải stop and start 2 lần thì mới sử dụng được (bất kì thơi gian nào trong ngày khi người dùng báo chậm), còn không thì sever rất chậm, khoảng 2 tháng lại đây em không hề viết thêm trigger hoặc store nào cả, file log của DB thì rất lơn nó phình lên tới 98GB, e đã xóa nó cho tạo file mới nhưng khoảng hơn 1 tháng là file log lại phình lên, em tính chuyển SET RECOVERY SIMPLE để xem có cải thiện tốc độ không, nhưng nó đang nằm mặc định ở Simple nên không thể làm gì. Mọi người cho em ý kiển để khắc phục tình trạng này, cảm ơn

  • tour phu quoc (16/01/2017 6:12 am)

    Mình cũng đau đầu về thằng này quá mà chưa có cách xử lý triệt để :(

  • thi bang lai xe may (07/05/2017 10:41 pm)

    Dung lượng cỡ khoảng bao nhiêu Mb thì an toàn nhỉ? Web mình database lên hơn 100Mb rồi. Đang lo lắng quá, làm các kiểu vẫn không giảm được là bao

Leave a Reply

Hướng dẫn: Để nhập mã T-SQL bạn dùng thẻ <pre lang="tsql"> và </pre>.
Ví dụ: <pre lang="tsql">SELECT * FROM MyTable</pre>