Lấy Lại Dữ Liệu Sau Khi Xóa

Vũ Huy Tâm

Bạn đã bao giờ nhỡ tay xóa mất một bảng (DROP TABLE) hoặc xóa sạch dữ liệu trong bảng (DELETE) của một database đang hoạt động rất nhộn nhịp, để rồi giật mình nhận ra mình vừa phạm một lỗi tày đình? Mồ hôi vã ra đầm đìa, nghe chuông điện thoại kêu mà giật mình thon thót, đầu óc quay cuồng nghĩ cách ăn nói thế nào cho phải… Hì hì làm cho kịch tính tí, nhưng quả thật những hoàn cảnh tương tự như vậy không phải hiếm. Đối với các DBA thường xuyên phải làm việc trực tiếp trên dữ liệu, những sự cố xảy ra do nhầm lẫn là không tránh khỏi. Rất may SQL Server đã tính đến tình huống này, và cung cấp các phương tiện cần thiết để lấy lại dữ liệu, với điều kiện database phải có những thiết lập đúng đắn từ trước.
Tuy nhiên bạn có thể thấy là vấn đề đã trở nên phức tạp hơn, câu lệnh không thể ROLLBACK lại được nữa vì SQL Server để chế độ mặc định là AUTO COMMIT. Khôi phục lại từ bản backup từ ngày hôm trước cũng không giải quyết được, vì như thế dữ liệu vừa mới được cập nhật trong ngày cũng sẽ mất tiêu luôn. Vấn đề đặt ra là cần lấy lại dữ liệu giống như thời điểm ngay trước khi chạy lệnh DELETE, chứ không phải từ ngày hôm qua. Một gợi ý cho bạn: log file luôn lưu lại tất cả các hành động diễn ra đối với database, bao gồm cả lệnh DELETE vừa xong. Đây là dấu vết duy nhất và cách làm của ta cũng là dựa vào đó để lần ngược lại.
Để có thể khôi phục lại được đòi hỏi ba điều kiện sau:
- database có chế độ RECOVERY MODE là FULL
- database đã từng được FULL BACKUP và bạn có trong tay file backup gần nhất
- log file chưa từng bị SHRINK kể từ sau lần full backup gần nhất.
Nếu một trong ba điều kiện trên bị vi phạm thì vấn đề kể như hết cách giải cứu.
Giả sử cả ba điều kiện trên được thỏa mãn và lần full backup gần đây nhất là đêm hôm trước. Bạn có thể khôi phục thông qua các bước sau (xem thêm script ở phần dưới):
1. Đóng lại tất cả các kết nối đến database để không tiếp nhận thêm dữ liệu
2. Ghi lại thời điểm xảy ra lệnh DELETE lỗi
3. Thực hiện BACKUP LOG cho database
4. Khôi phục lại database theo trình tự sau:
- RESTORE từ bản full backup đêm hôm trước
- RESTORE từ bản log backup với lựa chọn STOPAT = thời điểm ngay trước khi có sự cố
5. Và khi mọi việc đã hoàn tất, chuyển lại database sang chế độ hoạt động bình thường để các ứng dụng lại có thể kết nối vào database.

Script

Tạo database và bảng:

USE master
GO
IF DB_ID('TestDB') IS NOT NULL DROP DATABASE TestDB
GO
CREATE DATABASE TestDB
GO
USE TestDB
GO
CREATE TABLE dbo.Table1(ID INT IDENTITY, Ten VARCHAR(30) )
GO
INSERT INTO dbo.Table1(Ten)
SELECT 'Nguyen Van A' UNION ALL
SELECT 'Nguyen Van B' UNION ALL
SELECT 'Nguyen Van C'

Thực hiện full backup:

BACKUP DATABASE TestDB TO DISK = 'D:\Backup\TestDB.bak' WITH INIT

Thêm dữ liệu mới sau khi full backup:

INSERT INTO dbo.Table1(Ten)
SELECT 'Nguyen Van D' UNION ALL
SELECT 'Nguyen Van E'

Ba đoạn lệnh trên mô phỏng tình huống thực tế một database đã có chứa dữ liệu, được backup full lúc nửa đêm hôm trước, và trong ngày đã có thêm dữ liệu mới. Tại một thời điểm nào đó trong ngày bạn xóa mất dữ liệu do sơ suất:

DELETE FROM dbo.Table1

Sau khi xảy ra sự cố, việc tiếp theo đầu tiên bạn cần làm là đóng lại database, để không ai có thể tiếp tục cập nhật dữ liệu đến khi database được khôi phục xong. Bạn làm việc này bằng cách chuyển database về trạng thái SINGLE_USER (một người dùng). Vì bạn đang kết nối vào database, không ai khác có thể kết nối được nữa:

ALTER DATABASE TestDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Sau đó ghi lại thời điểm xảy ra sự cố:

SELECT GETDATE()

Khi đang chạy script cho bài viết này, thời điểm hiện tại của tôi là ’2010-12-07 17:51:03.990′.
Việc tiếp theo là backup log:

BACKUP LOG TestDB TO DISK = 'D:\backup\TestDB.trn' WITH INIT

Sau đó khôi phục lại database theo thứ tự bản full backup trước rồi đến bản log backup:

USE master
go
RESTORE DATABASE TestDB FROM DISK = 'D:\backup\TestDB.bak' WITH NORECOVERY
 
RESTORE DATABASE TestDB FROM DISK = 'D:\backup\TestDB.trn' WITH STOPAT='2010-12-07 17:50:00'

Điểm mấu chốt trong đoạn lệnh trên là mệnh đề STOPAT ở lệnh RESTORE thứ hai. Mục đích của nó là khôi phục lại database từ log backup nhưng dừng lại tại thời điểm được chỉ định. Khi các hành động xảy ra đối với database được lưu vào log file, nó cũng kèm theo thời điểm xảy ra hành động đó. Khi backup log file thì bản backup cũng chứa y nguyên các thông tin này. Vì thế khi restore từ log file với mệnh đề STOPAT, bạn đã yêu cầu hệ thống “tua” lại các hành động đã được áp dụng đối với database, nhưng dừng lại trước thời điểm có sự cố. Do đó lệnh DELETE trên không được thực hiện lại và bảng đã trở về trạng thái như cũ.

Hãy để ý ở mệnh đề STOPAT, tôi đã đẩy lùi thời gian lại một chút để đảm bảo thời điểm đó là trước khi xảy ra xóa dữ liệu. Khi chạy thử nghiệm bạn cần lưu ý điều này và chọn thời điểm cho thích hợp.
Và dữ liệu đã được khôi phục:

USE TestDB
GO
SELECT * FROM dbo.Table1
 
ID          Ten
----------- ------------------------------
1           Nguyen Van A
2           Nguyen Van B
3           Nguyen Van C
4           Nguyen Van D
5           Nguyen Van E
 
(5 ROW(s) affected)

Bước cuối cùng là chuyển lại database sang chế độ bình thường

ALTER DATABASE TestDB SET MULTI_USER

Vậy là vấn đề đã được giải quyết (sau khoảng nửa tiếng đến 1 tiếng gián đoạn sử dụng). Bây giờ là một câu hỏi giành cho bạn: Trong ví dụ trên tôi giả sử database chỉ có một backup duy nhất vào nửa đêm, và đó là full backup. Nếu ngoài ra database còn có các log backup định kỳ trong ngày (ví dụ mỗi tiếng 1 lần), thì việc khôi phục cần được thực hiện như thế nào?




Tags: , , , , ,

41 Comments
Posted on 7/12/2010 | Categories: Database Administration

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

Comments
  • Red Devilic (09/12/2010 4:30 am)

    Bài viết hay.

    Với câu hỏi của bác, theo em thì

    -Thực hiện Restore Full backup từ lúc nửa đêm

    - Sau đó thực hiện restore các backup định kỳ theo đúng thứ tự

    - Bước cuối cùng là RESTORE với tùy chọn STOPAT như trong bài đã hướng dẫn

  • Vũ Huy Tâm (10/12/2010 5:26 am)

    Vâng đúng là như vậy. Một điều nữa là khi đó lệnh backup log ở trong ví dụ trên cần bỏ lựa chọn "WITH INIT" hoặc cần backup vào một file riêng (khác với file dùng trong các backup định kỳ)

  • Hungbv (13/12/2010 4:53 am)

    Cảm ơn bạn. Bài viết rất hay. cũng đã có lần tôi gặp tình huống này mà không có cách nào giải quyết và chịu mất dữ liệu của 2 ngày, Cách giải quyết của mình là nhờ một nhóm các bạn kế toán lục lại chứng từ và nhập lại dữ liệu. Một kinh nghiệp để đời cho mình khi xóa dữ liệu

  • Tuấn (15/12/2010 7:25 pm)

    Phải nói là bạn rất ok!

  • chiphat (11/01/2011 4:15 pm)

    Cai nay hinh nhu o sql 2005 ha ban?

    sql2000 thi sao?

  • chiphat (11/01/2011 4:18 pm)

    Minh chay dong nay

    RESTORE DATABASE TestDB FROM DISK = 'D:vd.trn' WITH RECOVERY,STOPAT='2011-01-12 06:44:10.10'

    thi no bao loi nhu vay

    One or more of the options (stopat) are not supported for this statement. Review the documentation for supported options.

    the phai lam sao ha ban?

    • zBackup.vn (28/04/2016 3:10 am)

      Hi Chiphat,

      Tùy chọn STOPAT đâu dùng được cho lệnh RESTORE DATABASE. STOPAT chỉ dùng cho mục đích Point-in-Time Recovery. Mà Point-in-Time Recovery thì chỉ tiến hành được với lệnh RÉTORE LOG.

      Còn RETORE DATBASE thì nó cứ khôi phục database về thời điểm sao lưu, ko có point-in-time gì hết.

      Bạn check lại nhé!

  • Vũ Huy Tâm (12/01/2011 9:15 am)

    - lựa chọn STOPAT đã có từ bản 2000, bạn dùng SQL Server bản nào (express, standard…)?

    - bạn restore theo trình tự nào? restore từ full backup trước rồi đến từ log backup hay thằng từ log backup?

  • chunsang (08/03/2011 7:53 pm)

    su dung recover den cau lenh

    BACKUP LOG quanlithanhvien TO DISK = 'D:ackup hanhvien.trn' WITH INIT

    no bao:

    Msg 4208, Level 16, State 1, Line 1

    The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE.

    Msg 3013, Level 16, State 1, Line 1

    BACKUP LOG is terminating abnormally.

    khong biet lam sao vi minh moi hoc. mong cac bac chi bao dum

  • Vũ Huy Tâm (09/03/2011 4:56 am)

    nếu bạn đọc dòng thông báo lỗi thì sẽ hiểu ngay vấn đề – khi recovery model là SIMPLE thì lệnh BACKUP LOG không được phép thực hiện. Khi recovery model là SIMPLE thì các transaction log trong log file bị ghi đè lên một khi đã được COMMIT. Giống như bạn có một quyển sổ 10 trang để ghi nhật ký, đến khi dùng hết 10 trang thì quay trở lại trang đầu xóa nội dung cũ đi và ghi tiếp nội dung mới. Vì thế log file không còn lưu được toàn bộ các transaction theo trình tự thời gian và do đó, backup log không có tác dụng. Bạn cần chuyển recovery model sang FULL.

    • Dushyant (04/07/2015 5:26 pm)

      Your article was exlnelcet and erudite.

  • thanhtinhng (19/04/2011 6:05 pm)

    Cảm ơn bạn về những bài viết bổ ích trong blog này.Tiện đây bạn cho mình hỏi,khi tiên hành backup log mình gặp lỗi này mà không biết xử sao :

    Msg 4214, Level 16, State 1, Line 1

    BACKUP LOG cannot be performed because there is no current database backup.

    Bạn giải đáp giúp mình nhé,

  • Vũ Huy Tâm (21/04/2011 10:04 am)

    @thanhtinhng: Backup log chỉ có thể tiến hành sau khi bạn đã thực hiện full backup hoặc differential backup.

  • thanhtinhng (22/04/2011 12:50 am)

    Oh,cảm ơn bạn nhiều nhé.Mình làm được rồi.

    À,bạn có bài viết nào về mã hóa dữ liệu nào không?mình đang thực hành mà vướng mắc nhiều quá,nếu có thể hy vọng bạn post lên một bài để mọi người cùng tham khảo nhé.

  • Gau do (06/06/2011 11:50 pm)

    Khi chạy đến câu lệnh này :
    USE master
    go
    RESTORE DATABASE TestDB FROM DISK = ‘D:\backup\TestDB.bak’ WITH NORECOVERY
    RESTORE DATABASE TestDB FROM DISK = ‘D:\backup\TestDB.trn’ WITH STOPAT=’2011-06-07 10:23:10′

    thì báo lỗi:

    Msg 3101, Level 16, State 1, Line 1
    Exclusive access could not be obtained because the database is in use.
    Msg 3013, Level 16, State 1, Line 1
    RESTORE DATABASE is terminating abnormally.
    Msg 3117, Level 16, State 4, Line 2
    The log or differential backup cannot be restored because no files are ready to rollforward.
    Msg 3013, Level 16, State 1, Line 2
    RESTORE DATABASE is terminating abnormally.

    Bác giúp em xử lý nó cái nhé. Tiện đây cho em hỏi thêm. Làm cách nào mình biết ai đã làm gì với DB. VD: hôm qua Nhan vien a làm 1 số thao tác trên DB. Giờ mình muốn biết NV a đó thao tác những gì ?

  • Vũ Huy Tâm (07/06/2011 1:39 pm)

    Lỗi này là do database đang có connection khác kết nối vào, bạn cần chạy lệnh này trước khi restore (trong cùng một cửa sổ):

    ALTER DATABASE TestDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

    Về câu hỏi thứ hai của bạn, nếu bạn cần theo dõi những thay đổi về dữ liệu việc này gọi là audit log. Tôi chưa làm bao giờ nên không rõ. Còn nếu thay đổi về schema (cấu trúc của database) thì từ bản 2008 bạn có thể mở “Schema changes history” report (right click vào database, chọn reports->standard reports->Schema changes history).

  • Cường (10/08/2011 5:45 am)

    Bài viết hay, xin cảm ơn tác giả

  • Quân (22/11/2011 4:04 am)

    Bài viết rất hay, xin cảm ơn anh.
    Em cũng có một thắc mắc , như bài viết anh đã viết, thì em nghĩ trong SQL có lưu lại vết xóa database.
    Nếu đúng như thế, thì nó nằm ở table nào? Cảm ơn anh trước.

    • zBackup.vn (01/05/2016 5:54 am)

      Mọi thao tác làm thay đổi database (INSERT, UPDATE, DELETE,…) đều được lưu vào Transaction Log của database đó Nên “vết xóa database” như bạn nói chính là một log record ghi nhận thao tác xóa đó trong Transaction Log. Chứ ko lưu ở database nào khác.

  • Nhọ (17/05/2012 5:33 am)

    Nhọ, vừa hôm trước nhỡ tay drop 1 bảng trong db, chưa đọc bài này mất sạch dữ liệu, may mà nó ko quan trong lắm. thanks

  • duy an (10/11/2012 8:58 pm)

    Cám ơn anh, bài viết rất hay.

  • sỏi (28/07/2013 8:41 pm)

    Cho mình hỏi nếu sau khi mình retore log lại nhưng chọn thời điểm sai nên dữ liệu không trả về đúng lúc trước khi update (mình sử dụng update record) thì làm sao để retore lại.
    Mình có chọn retore bản full backup lại trước như bài hướng dẫn thì lúc này có thông báo lỗi:

    Msg 3159, Level 16, State 1, Line 1
    The tail of the log for the database “TestDB” has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log.
    Msg 3013, Level 16, State 1, Line 1
    RESTORE DATABASE is terminating abnormally.

    Lúc này mình restore bản full backup with replace thì ok, nhưng khi restore log thì báo lỗi:

    Msg 3117, Level 16, State 4, Line 1
    The log or differential backup cannot be restored because no files are ready to rollforward.
    Msg 3013, Level 16, State 1, Line 1
    RESTORE DATABASE is terminating abnormally.

    Vậy thì khi đã restore log sai thời điểm thì làm sao để restore lại?
    Cảm ơn nhiều

    • sỏi (28/07/2013 9:03 pm)

      Mình tự trả lời luôn :)
      Nếu lỡ restore log sai thời điểm nên không phục hồi được dữ liệu như mong muốn thì:
      restore bản full backup lại 1 lần nữa và phải thêm WITH REPALCE, NORECOVERY thì mới cho restore
      và lúc này có thể restore log bình thường
      Nếu thấy ý mình sai hoặc có cách nào khác thì nhờ chỉ giáo thêm
      Thanks

  • Vũ Huy Tâm (30/07/2013 10:17 am)

    Sỏi: Cách bạn làm là đúng rồi. Khi đã restore mà không chỉ định WITH NORECOVERY (nó sẽ mặc định là RECOVERY) thì database đã sẵn sàng hoạt động và không thể restore thêm từ diff hoặc transaction log backup được nữa. Bạn cần thực hiện lại quá trình trên bắt đầu bằng restore từ bản full backup với lựa chọn NORECOVERY

  • ecompc (31/07/2013 5:06 am)

    Mình thấy phải canh chính xác đến từng giây thời điểm mà mình chạy delete thì mới restore đc
    nên mình phải thêm 2 cái getdate trước và sau khi chạy delete
    [sql]
    select getdate()
    DELETE FROM dbo.Table1
    select getdate()
    [/sql]

    Nhưng trên thực tế, sau khi lỡ tay delete thì phải mất khoảng thời gian bình tình hồi hợp suy nghĩ, rồi chuyển datbase về singleuser, rồi backup log,nhiêu đó thời gian thì lúc này mới thực hiện GETDATE() nó quá trễ rồi,
    ko biết có cách nào khắc phục hay không

  • ecompc (31/07/2013 5:15 am)

    Nếu stopat mà sớm hoặc trễ hơn thời gian delete vài giây thì cũng bị lỗi này

    Msg 4335, Level 16, State 1, Line 3
    The specified STOPAT time is too early. All or part of the database is already rolled forward beyond that point.

    ??Làm sao mình có thể canh đúng thời gian delete đc, trong khi nếu mình lỡ tay delete thì ít ai có thể kịp thời suy nghĩ hành động GETDATE() ngay lúc đó đc

  • Vũ Huy Tâm (12/08/2013 1:52 pm)

    Hôm nọ đã viết 1 reply dài, viết xong thì đúng lúc server bị down nên mất luôn ;)
    Lỗi “STOPAT time is too early” là do bạn đặt stopat sớm hơn thời điểm bắt đầu của file log backup đó. Bạn không cần biết chính xác thời điểm delete nhưng cần chọn STOPAT trước đó và càng gần thời điểm đó càng gần càng tốt. Có thể thử restore vài lần với các giá trị STOPAT xê dịch 1 chút đến khi kết quả được như ý thì thôi (nếu database ko quá lớn). Một điểm nữa cần lưu ý là database đã có scheduled backup sẵn, ví dụ 5 phút chạy log backup 1 lần. Trong trường hợp đó thì không cần làm log backup nữa, mà phải tìm đến log backup file đã được tạo để restore. Lưu ý là log backup chỉ sao lưu những transaction từ lần full/diff/log backup trước đó.

  • ecompc (12/08/2013 10:16 pm)

    Theo như bài viết của anh, thì thứ tự các bước

     DELETE FROM dbo.Table1

    Sau đó chuyển DB về single user, rồi thực hiện getdate

     SELECT GETDATE()

    Sau đó mới tiến hành Backup log

    BACKUP LOG TestDB TO DISK = 'D:\backup\TestDB.trn' WITH INIT

    Em ko hiểu câu chỗ này:

    Lỗi “STOPAT time is too early” là do bạn đặt stopat sớm hơn thời điểm bắt đầu của file log backup đó
    
    Tại vì lệnh GETDATE() mình thực hiện trước lệnh BACKUP LOG, nên kiểu gì nó cũng sớm hơn thời điểm bắt đầu của lệnh BAckup log
    ?
    mong anh giải thích chỗ này giúp em
  • Vũ Huy Tâm (13/08/2013 3:02 pm)

    À backup log sao lưu các transaction từ lần backup trước, ví dụ:
    - backup full lúc 5h sáng
    - trong buổi sáng diễn ra các giao dịch insert/update dữ liệu…
    - vào khoảng 10h sáng bạn trót xóa bảng.
    - sau 1 lúc lúng túng bạn mới chuyển database về single user và chạy getdate() vào lúc 10h5′. Sau đó đến 10h8′ bạn mới backup log. Như thế backup log này chứa tất cả các giao dịch từ 5h sáng đến 10h8′, và tất nhiên chứa cả lệnh xóa bảng.

    Khi restore từ backup log, bạn cần đặt stopat = thời điểm trước khi xảy ra lệnh xóa. Bạn có thể chọn 10′ và thấy nếu dữ liệu vẫn bị mất thì lùi lại 9h58′…

    Trong reply của tôi có 1 điểm sai : “Lỗi “STOPAT time is too early” là do bạn đặt stopat sớm hơn thời điểm bắt đầu của file log backup đó” <– cái này không đúng. Lỗi trên xảy ra khi database đã được đưa về trạng thái giống như thời điểm sau stopat. Ví dụ bạn đặt stopat = 4h59 (trước 5h là thời điểm full backup), vì sau khi restore từ full backup, database đã được đưa về giống như thời điểm 5h, bạn không thể đưa nó lùi về trước đấy được nữa.

    • ecompc (14/08/2013 3:57 am)

      Thanks bác tâm đã nhiệt tình, em sẽ test lại xem đúng vậy ko rồi sẽ comment :D
      :D

    • ecompc (14/08/2013 4:32 am)

      Thanks bác Tâm, em đã test lại và quả thật đúng y những j bác nói
      Vậy là cũng đã hiểu rõ phần này rồi. Thanks rất nhiều

      Ah, mà còn 1 vấn đề nữa đó là các Database mình restore bị sai hay bị lỗi thì nó có dạng :
      Database(Restoring…)

      Vấn đề là mấy cái Database nó e ko còn giữ file backup bak nữa, nên giờ xóa nó cũng ko xóa được luôn
      hic, hệ quả em test mấy bữa giờ , giờ nhìn cây Database nó xấu quá,

      Làm sao mình xóa đc mấy cái database bị lỗi (Restoring..) đó

  • tung (11/11/2013 5:24 am)

    Bác tâm cho em hỏi câu lệnh tạo log backup với ạ.

  • nguyễn hòa (16/06/2014 10:44 am)

    hix! Anh cho em hỏi với, lúc sau khi lệnh xóa em lại trót backup lại database do không biết mình xóa nhầm, giờ có cách nào lấy lại được dữ liệu không ạ?

  • Phương Tâm (01/09/2015 12:20 am)

    Chào mọi người, mình xin đóng góp ý kiến, vẫn đề mẫu chốt ở đây là thực hiện full backup và thời gian
    Bản full backup của cty mình là 157Gb, và dữ liệu liên tục nạp vào vì là của nhà máy sản xuất, nếu mình dừng kết nối lập tức các phòng ban sẽ gọi réo la ó lộn cái bản (nếu đó là backup chút xíu), giả sử backup hết 2 tiếng thì các bạn biết rồi chắc xác định có giấy.
    Còn nếu mình chờ tới lúc 18h tối hết người sử dụng phần mềm thì khi mình làm theo hướng dẫn thao tác của Admin thì vẫn đề phát sinh, những dữ liệu đã được insert vào DB từ thời điểm BỊ LỖI tới 18h thì nó sẽ đi đầu về đâu.
    Nếu dữ liệu là một chuỗi thì việc xác định khúc nào của chuỗi bị mất, xác định càng chính xác tọa độ thì khôi phục cầng ít thời gian và đảm bảo cái chuỗi vẫn đang được thêm dữ liệu

  • zBackup.vn (28/04/2016 3:14 am)

    Hi anh Vũ Huy Tâm,

    Bài viết thiết thực quá anh. Không những thế, anh reply rất chi tiết nên không chỉ giúp được trực tiếp cho bạn đang hỏi mà còn giúp được cho những bạn khác gặp vấn đề tương tự.

    Các bạn bên em cũng biết chút chút về backup recovery cho SQL Server nên sẽ phụ thêm anh giải đáp cho các anh em DBA, IT Admin trong đề tài này nhé.

    Thanks anh a lot!

    - zBackup.vn

    • Vũ Huy Tâm (29/04/2016 10:34 am)

      Cám ơn các bạn đã cùng tham gia!

      • zBackup.vn (30/04/2016 3:20 pm)

        Thanks anh đã cho phép.

        Một số thắc mắc cách đã khá lâu (em đoán anh ko đủ thời gian reply hết), giờ lôi lên thì giống đào mộ. Nhưng có thể các bạn khác cần tìm những kiến thức này (search Google). Nên thắc mắc nào nhắm có thể trả lời đc thì em reply để các bạn khác vào xem biết câu trả lời a nhé.

  • Văn Tuấn Hưng (01/07/2016 3:50 am)

    Anh ơi cho em hỏi với.
    Em có 1 cái DB bị xóa mất DL mấy tháng
    E có 1 bản backup full gần nhất là ngày 21/04
    Đến ngày hôm nay 01/7 em mới backup file log trn
    E làm theo các bước ở trên đế lúc chạy đoạn
    RESTORE log A1_SXKD_2016 FROM DISK = ‘D:\A1BACKUP.trn’
    WITH STOPAT=’2016-06-29 01:07:34.430′
    thì nó báo là :
    The log in this backup set begins at LSN 400000000012100001, which is too late to apply to the database. An earlier log backup that includes LSN 124000000154800001 can be restored.

    Ko biét trường hợp này còn cứu đc DL ko anh nhỉ

  • hứa thanh trông (18/01/2017 10:17 am)

    moi nguoi oi, giup do minh với, mình lỡ tay delect databases mà data đó mình không có backup thì sao hả? có khôi phục được không, ai giúp mình với mình sẽ hậu ta. trả bạn nào giup đỡ mình bang cach mình se nap card dt. giúp do minh voi moi nguoi oi

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>