SQL Server 2008およびより高いバージョンのデータベース復元方法のログのバックアップ


データを誤魔化したり、誤って操作したりする人をよく見かけます。特にudateとdeleteの時はwhereを入れていません。人は聖賢ではないのです。過ちは理解できますが、大目に見てはいけません。これは後で言ってください。今は問題を解決します。
        このような状況になると、たいていはバックアップをしていません。さもなければ、質問も来ません。まず冷静にしてください。そうしないともっと大きな災難があります。あなたが諦めるまで。
解決方法:
       このような問題については、主に誤操作前のデータを探し出すことです。2008年までに、有名なツールであるLog Exploerがあります。とても使いやすいと聞きました。しかし、唯一の残念なことに、2008およびより高いバージョンはサポートされていません。この時、他の第三者ツールを除いて、最もよく使われているのは本明細書で述べた方法です。ログの最後のバックアップです。本論文の実験環境200 8 R 2は、2008年とそれ以上のバージョンに対してこの方法を使うことができますが、2005年も大丈夫です。2000はあまり使われていません。試したことがありません。ただし、2008年の前にLog Exploerを使うことができますので、この方法を使う必要はありません。
      下の図は文語とともに操作方法を説明します。原理は本文の範囲ではないです。そして、間違いがあったと信じています。誰も原理を見られないと思います。
ステップ:
(1)、データベースの復旧モードを確認します。


またはスクリプトを使ってチェックします。

SELECT recovery_model,recovery_model_desc 
FROM sys.databases 
WHERE name ='
結果は以下の通りです

        データベースの復旧モードを確保するには少なくとも「簡単」ではない。どのように完全なモードに修正するかについては、これらは多く話す必要がないと思います。 
       重要な環境については、お客様の正式な環境(通称生産環境)だけでなく、「完全回復モード」を使用することを強く推奨しています。LOGGED、シンプル(SIMPPLE)では、完全復帰モードで発生したログは大きいですが、問題が発生した時には、これらは大したことではないと思います。また、正式な環境に対して完全な回復モードを使わないという理由も考えられませんでした。管理が適切でさえあれば、完全回復モードのログもあまり変態ではない。 
(2)、ここには他のステップが含まれています。少なくとも一回の完全バックアップをしたことがあります。すべてのタイプのバックアップは完全なバックアップに基づいていますので、少なくとも一回のバックアップがないと、他のタイプのバックアップは全部余分です。ここで強調してください。新しいデータベースを作成した後、バックアップを強制することも強く勧めます。

SELECT database_name,recovery_model,name 
FROM ms
上の文を使って大体において、これらのデータベースのバックアップが見られます。テストのために、何回かバックアップを取っています。この時点でバックアップができました。

(3)他の人がデータベースに接続しないことを確認し、ログの最後のバックアップを行う:
まずデータを作成します。
tempdbはいつまでも簡単な回復モードなので、ケースには不向きです。 
ここではマイクロソフトのデータベース例としてAdventureWorksを使います。 

*/ 
USE AdventureWorks 
GO 
IF OBJECT_ID('testRestore') IS NOT NULL 
 DROP TABLE testRestore 
GO 
CREATE TABLE testRestore 
 ( 
  id INT IDENTITY(1, 1) , 
  NAME VARCHAR(50) 
 ); 
--      :  
INSERT INTO testRestore(Name) 
SELECT 'test1' 
UNION ALL 
SELECT 'test2' 
UNION ALL 
SELECT 'test3' 
UNION ALL 
SELECT 'test4' 
UNION ALL 
SELECT 'test5' 
UNION ALL 
SELECT 'test6' 
UNION ALL 
SELECT 'test7' 
UNION ALL 
SELECT 'test8' 
SELECT * FROM testRestore 
検査の結果:

それから削除操作をします。位置を決めるためにいつ発生しましたか?Waitfor命令を加えて、ある時間に発生させます。このように回復する時に正確性があります。

USE AdventureWorks 
GO 
WAITFOR TIME '21:45' 
DELETE FROM dbo.testRestore 
データを見てみます。

USE AdventureWorks 
GO 
SELECT * FROM dbo.testRestore 

ここまで来ると、災難は出てきましたが、冷静さを忘れないようにしてください。
次は本文の重点から始まります。一回のログのバックアップをします。一番重要なのは【バックアップログの末尾】を選ぶことです。

それから【オプション】ページで選択します。【事務日誌】を除いて、他の赤い枠の小包のところはチェックの場所を強く提案します。また、データベースには他の人が接続しないようにしてください。バックアップログの末尾はデータベースを元に戻すため、他のセッションの接続を拒否します。他の接続を続けて開けば、バックアップできません。

そして確定を押すと、もちろん上の【シナリオ】を使って文を作ることができます。

USE Master 
GO 
BACKUP LOG [AdventureWorks] TO DISK = N'E:\AdventureWorks.bak' WITH NO_TRUNCATE , NOFORMAT, NOINIT, NAME = N'AdventureWorks-       ', SKIP, NOREWIND, NOUNLOAD, NORECOVERY , COMPRESSION, STATS = 10, CHECKSUM 
GO 
declare @backupSetId as int 
select @backupSetId = position from msdb..backupset where database_name=N'AdventureWorks' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'AdventureWorks' ) 
if @backupSetId is null begin raiserror(N'    。      “AdventureWorks”     。', 16, 1) end 
RESTORE VERIFYONLY FROM DISK = N'E:\AdventureWorks.bak' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND 
GO 


このとき、データベースは【復元中】の状態になります。

バックアップが見つからなかったら次の文で確認して、spidを殺してもいいです。
SELECT  * FROM sys.sysprocesses WHERE dbid=DB_ID(''AdvientureWorks') 
実行結果:

そしてキルが落ちる。
バックアップを続けます。
 図のように復元します。
まず完全なバックアップを元に戻して、一番近いのを選んでください。ログのバックアップの特性(後で他の文章にします。)のため、最後のバックアップだけを確認しますので、最新のものを選んでください。でないと元に戻せません。

ここにもう一つ注意事項があります。選択を覚えてください。

次にログファイルを復元します。これは一番重要なステップです。

そして:

実験の時に問題があったので、後でやり直しました。22時19分まで選択しました。私は22時20分にデータを削除しました。ここはあまり気にしなくてもいいです。時間を間違えて削除する時間まで指定すればいいです。ログのバックアップは最後のバックアップファイルですので、赤枠の部分を選んでください。

今もう一度チェックします。

データが復元されました。
まとめ:
普段はバックアップをしないで、問題があったら、急いでください。これはいい加减にして、自分で取ります。また、頭が熱くなった人はldfを見てから直接削除します。その後問題が発生したらマイクロソフトを責めないでください。
この文章の中の方法はちょっとくどいように見えますが、実際に何回か使ったらいいと思います。しかし、ステップの提案は上記の通りです。一度操作を間違えたら、面倒くさいです。ここでもう一度強調します。冷静で落ち着いて!!!!!!!!
この方法にはいくつかの欠点があります。
1、誤操作を発見したら、多くの人が操作をしました。元に戻すと、他の人の操作が流れてしまいます。誤操作が発生したら、すぐに他の人のデータベース操作を停止します。
2、 この方法はデータベースを独占しますので、こっそり回復してはいけません。誤りを認めよう。
コアデータテーブルについては、まず予防的な操作を行う必要があります。
以上が本文の全部です。皆さんの勉強に役に立ちたいです。