㈠ 事務日誌備份既備份資料庫的數據文件和日誌文件存儲在相同的位置
1、選擇數據 「DJABC」，滑鼠右鍵彈出菜單，選擇「所有任務」「分離資料庫」。
2、分離資料庫：
如果有其他程序當前正連接到本資料庫，請點擊「清除」按鈕清除所有連接，然後按下
「確定」按鈕即可完成對資料庫的分離。
3、刪除資料庫的日誌文件：資料庫一旦被分離後，你可以直接刪除資料庫的日誌文件。
4、附加資料庫：依次選擇菜單 「資料庫」「所有任務」「附加資料庫」，系統會彈出附加資料庫窗口。
5、選擇數據文件和附加資料庫名稱，完成後按下確定即可將剛剛分離的資料庫重新加到當前 sqlserver伺服器上。
6、所有完成後，系統重新創建日誌文件，新創建的日誌文件大小為1K，等到以後長到很大時，再執行上面的日誌清除過程即可。
㈡ sql 存儲過程的日誌怎麼寫
方法1：
第一步：
backup
log
database_name
with
no_log
或者
backup
log
database_name
with
truncate_only
--no_log和truncate_only是在這里是同義的，隨便執行哪一句都可以
第二步：
1.收縮特定資料庫的所有數據和日誌文件，執行
dbcc
shrinkdatabase
(database_name,[,target_percent])--database_name是要收縮的資料庫名稱；target_percent是資料庫收縮後的資料庫文件中所要的剩餘可用空間百分比
2.收縮一次一個特定資料庫中的數據或日誌文件，執行
dbcc
shrinkfile(file_id,[,target_size])
--file_id是要收縮的文件的標識
(id)
號,若要獲得文件
id，請使用
file_id
函數或在當前資料庫中搜索
sysfiles；target_size是用兆位元組表示的所要的文件大小（用整數表示）。如果沒有指定，dbcc
shrinkfile
將文件大小減少到默認文件大小
兩個dbcc都可以帶上參數notruncate或truncateonly，具體意思看幫助。
方法2（這個方法在sqlserver2000的環境下做一般能成功，在sqlserver7及以下版本就不一定了）：
第一步：
先備份整個資料庫以備不測
第二步：
備份結束後，在query
analyzer中執行如下的語句：
exec
sp_detach_db
yourdbname,true
--卸除這個db在mssql中的注冊信息
第三步：
到日誌的物理文件所在的目錄中去刪除該日誌文件或者將該日誌文件移出該目錄
第四步：
在query
analyzer中執行如下的語句：
exec
sp_attach_single_file_db
yourdbname,'d:\mssql7\data\yourdbname_data.mdf'
--以單文件的方式注冊該db，如果成功則mssql將自動為這個db生成一個500k的日誌文件。
以上方法在清除log日誌中均有效。
但，能否讓sql
server
不產生log日誌呢？以上方法好像均無效。
我這兒正好有個case：
我客戶的sql
server每天都會產生4，500m的log日誌，每天都清除一下，非常不便。有沒有辦法實現不產生log日誌呢？
我分析了一下客戶產生log日誌的原因，並且做了相應測試。
客戶是每天將資料庫清空，從總系統中將數據導入到sql
server里。我感決sqlserver在插入時產生log不大，在delete整個庫時產生log極大。
比如：
select
*
into
test_2
from
b_bgxx
共45000條記錄，產生十幾m
log，如果
delete
from
test_2
產生80多m
log
，這明顯存在問題。
雖然可以換成：
truncate
table
test_2
但我還是希望能找到不產生log的方法。就如oracle不產生歸檔一樣。
㈢ mysql binglog，redolog先寫哪個
mysql通過內部XA事務協調處理binlog、redolog 的寫入
在事務提交時，先寫二進制日誌，再寫innodb存儲引擎的重做日誌。對上述兩個操作的要求是原子的，即二進制日誌和重做日誌必須同事寫入。若二進制日誌先寫了，而在寫入innodb存儲引擎時發生了宕機，那麼slave可能會接收到master傳過去的二進制日誌並執行，最終導致主從不一致的情況
如果在innodb存儲引擎提交前，MySQL資料庫宕機了，那麼MySQL資料庫在重啟後會先檢查准備的UXID事務是否已經提交，若沒有，則在存儲引擎層再進行一次提交操作！
㈣ sql server資料庫怎麼寫日誌
sql server資料庫怎麼寫日誌
：查看sql資料庫操作日誌的方法步驟： 1、用windows身份驗證登陸資料庫，點擊【連接】； 2、展開資料庫伺服器下面的【管理】【SQL Server日誌】； 3、雙擊【當前】可以打開【日誌文件查看器】裡面有所有的運行日誌；
㈤ 資料庫中可以有幾個 主文件，次文件，日誌文件，索引文件
首要文件:這個文件是必須有的，而且只能有一個。這個文件額外存放了其他文件的位置等信息.擴展名為.mdf
次要文件:可以建任意多個，用於不同目的存放.擴展名為.ndf
日誌文件：存放日誌,擴展名為.ldf
㈥ oracle 數據文件 日誌文件 寫法
深入分析Oracle資料庫日誌文件
作為Oracle DBA，我們有時候需要追蹤數據誤刪除或用戶的惡意操作情況，此時我們不僅需要查出執行這些操作的資料庫賬號，還需要知道操作是由哪台客戶端（IP地址等）發出的。針對這些問題，一個最有效實用而又低成本的方法就是分析Oracle資料庫的日誌文件。本文將就Oracle日誌分析技術做深入探討。
一、如何分析即LogMiner解釋
從目前來看，分析Oracle日誌的唯一方法就是使用Oracle公司提供的LogMiner來進行， Oracle資料庫的所有更改都記錄在日誌中，但是原始的日誌信息我們根本無法看懂，而LogMiner就是讓我們看懂日誌信息的工具。從這一點上看，它和tkprof差不多，一個是用來分析日誌信息，一個則是格式化跟蹤文件。通過對日誌的分析我們可以實現下面的目的：
1、查明資料庫的邏輯更改；
2、偵察並更正用戶的誤操作；
3、執行事後審計；
4、執行變化分析。
不僅如此，日誌中記錄的信息還包括：資料庫的更改歷史、更改類型（INSERT、UPDATE、DELETE、DDL等）、更改對應的SCN號、以及執行這些操作的用戶信息等，LogMiner在分析日誌時，將重構等價的SQL語句和UNDO語句（分別記錄在V$LOGMNR_CONTENTS視圖的SQL_REDO和SQL_UNDO中）。這里需要注意的是等價語句，而並非原始SQL語句，例如：我們最初執行的是delete a where c1 <>cyx;，而LogMiner重構的是等價的6條DELETE語句。所以我們應該意識到V$LOGMNR_CONTENTS視圖中顯示的並非是原版的現實，從資料庫角度來講這是很容易理解的，它記錄的是元操作，因為同樣是delete a where c1 <>cyx;語句，在不同的環境中，實際刪除的記錄數可能各不相同，因此記錄這樣的語句實際上並沒有什麼實際意義，LogMiner重構的是在實際情況下轉化成元操作的多個單條語句。
另外由於Oracle重做日誌中記錄的並非原始的對象（如表以及其中的列）名稱，而只是它們在Oracle資料庫中的內部編號（對於表來說是它們在資料庫中的對象ID，而對於表中的列來說，對應的則是該列在表中的排列序號：COL 1, COL 2 等），因此為了使LogMiner重構出的SQL語句易於識別，我們需要將這些編號轉化成相應的名稱，這就需要用到數據字典（也就說LogMiner本身是可以不用數據字典的，詳見下面的分析過程），LogMiner利用DBMS_LOGMNR_D.BUILD()過程來提取數據字典信息。
LogMiner包含兩個PL/SQL包和幾個視圖：
1、dbms_logmnr_d包，這個包只包括一個用於提取數據字典信息的過程，即dbms_logmnr_d.build()過程。
2、dbms_logmnr包，它有三個過程：
add_logfile(name varchar2, options number) - 用來添加/刪除用於分析的日誌文件；
start_logmnr(start_scn number, end_scn number, start_time number,end_time number, dictfilename varchar2, options number) - 用來開啟日誌分析，同時確定分析的時間/SCN窗口以及確認是否使用提取出來的數據字典信息。
end_logmnr() - 用來終止分析會話，它將回收LogMiner所佔用的內存。
與LogMiner相關的數據字典。
1、v$logmnr_dictionary，LogMiner可能使用的數據字典信息，因logmnr可以有多個字典文件，該視圖用於顯示這方面信息。
2、v$logmnr_parameters，當前LogMiner所設定的參數信息。
3、v$logmnr_logs，當前用於分析的日誌列表。
4、v$logmnr_contents，日誌分析結果。
二、Oracle9i LogMiner的增強：
1、支持更多數據/存儲類型：鏈接/遷移行、CLUSTER表操作、DIRECT PATH插入以及DDL操作。在V$LOGMNR_CONTENTS的SQL_REDO中可以看到DDL操作的原句（CREATE USER除外，其中的密碼將以加密的形式出現，而不是原始密碼）。如果TX_AUDITING初始化參數設為TRUE，則所有操作的資料庫賬號將被記錄。
2、提取和使用數據字典的選項：現在數據字典不僅可以提取到一個外部文件中，還可以直接提取到重做日誌流中，它在日誌流中提供了操作當時的數據字典快照，這樣就可以實現離線分析。
3、允許對DML操作按事務進行分組：可以在START_LOGMNR()中設置COMMITTED_DATA_ONLY選項，實現對DML操作的分組，這樣將按SCN的順序返回已經提交的事務。
4、支持SCHEMA的變化：在資料庫打開的狀態下，如果使用了LogMiner的DDL_DICT_TRACKING選項，Oracle9i的LogMiner將自動對比最初的日誌流和當前系統的數據字典，並返回正確的DDL語句，並且會自動偵察並標記當前數據字典和最初日誌流之間的差別，這樣即使最初日誌流中所涉及的表已經被更改或者根本已經不存在，LogMiner同樣會返回正確的DDL語句。
5、在日誌中記錄更多列信息的能力：例如對於UPDATE操作不僅會記錄被更新行的情況，還可以捕捉更多前影信息。
6、支持基於數值的查詢：Oracle9i LogMiner在支持原有基於元數據（操作、對象等）查詢的基礎上，開始支持基於實際涉及到的數據的查詢。例如涉及一個工資表，現在我們可以很容易地查出員工工資由1000變成2000的原始更新語句，而在之前我們只能選出所有的更新語句。
三、Oracle8i/9i的日誌分析過程
LogMiner只要在實例起來的情況下都可以運行，LogMiner使用一個字典文件來實現Oracle內部對象名稱的轉換，如果沒有這個字典文件，則直接顯示內部對象編號，例如我們執行下面的語句：
delete from "C"."A" where "C1" = 『gototop』 and ROWID = AAABg1AAFAAABQaAAH;
如果沒有字典文件，LogMiner分析出來的結果將是：
delete from "UNKNOWN"."OBJ# 6197" where "COL 1" = HEXTORAW(d6a7d4ae) and ROWID
= AAABg1AAFAAABQaAAH;
㈦ SQL Server日誌作用以及為什麼先寫日誌後寫數據
今天在看Oracle的BackupGroundProcess，里邊有一段是寫到為什麼先寫日誌後寫數據的：LGWR, on the other hand, does lots of sequential writes to the redo log. This is an important distinction and one of the reasons that Oracle has a redo log and the LGWR process as well as the DBWn process. Scattered writes are significantly slower than sequential writes. By having the SGA buffer dirty blocks and the LGWR process do large sequential writes that can re-create these dirty buffers, we achieve an increase in performance. 其實SQL Server也是一樣，每一個SQL Server的資料庫都會按照其修改數據(insert,update,delete)的順序將對應的日誌記錄到日誌文件.SQL Server使用了Write-Ahead logging技術來保證了事務日誌的原子性和持久性.而這項技術不僅僅保證了ACID中的原子性(A)和持久性(D),還大大減少了IO操作，把對數據的修改提交到磁碟的工作交給lazy-writer和checkpoint.預寫式日誌（Write-Ahead Logging (WAL)）SQL Server使用了WAL來確保了事務的原子性和持久性.實際上，不光是SQL Server,基本上主流的關系資料庫包括oracle,mysql,db2都使用了WAL技術.WAL的核心思想是:在數據寫入到資料庫之前，先寫入到日誌.因為對於數據的每筆修改都記錄在日誌中，所以將對於數據的修改實時寫入到磁碟並沒有太大意義，即使當SQL Server發生意外崩潰時，在恢復(recovery)過程中那些不該寫入已經寫入到磁碟的數據會被回滾(RollBack),而那些應該寫入磁碟卻沒有寫入的數據會被重做(Redo)。從而保證了持久性(Durability)但WAL不僅僅是保證了原子性和持久性。還會提高性能.硬碟是通過旋轉來讀取數據,通過WAL技術，每次提交的修改數據的事務並不會馬上反映到資料庫中，而是先記錄到日誌.在隨後的CheckPoint和lazy Writer中一並提交,如果沒有WAL技術則需要每次提交數據時寫入資料庫:而使用WAL合並寫入，會大大減少磁碟IO：也許你會有疑問，那每次對於修改的數據還是會寫入日誌文件.同樣消耗磁碟IO。上篇文章講過，每一筆寫入日誌的記錄都是按照先後順序，給定順序編號的LSN進行寫入的，日誌只會寫入到日誌文件的邏輯末端。而不像數據那樣，可能會寫到磁碟的各個地方.所以，寫入日誌的開銷會比寫入數據的開銷小很多。SQL Server修改數據的步驟SQL Server對於數據的修改,會分為以下幾個步驟順序執行:1.在SQL Server的緩沖區的日誌中寫入」Begin Tran」記錄2.在SQL Server的緩沖區的日誌頁寫入要修改的信息3.在SQL Server的緩沖區將要修改的數據寫入數據頁4.在SQL Server的緩沖區的日誌中寫入」Commit」記錄5.將緩沖區的日誌寫入日誌文件6.發送確認信息(ACK)到客戶端(SMSS,ODBC等）可以看到,事務日誌並不是一步步寫入磁碟.而是首先寫入緩沖區後，一次性寫入日誌到磁碟.這樣既能在日誌寫入磁碟這塊減少IO，還能保證日誌LSN的順序.上面的步驟可以看出，即使事務已經到了Commit階段，也僅僅只是把緩沖區的日誌頁寫入日誌，並沒有把數據寫入資料庫.那將要修改的數據頁寫入資料庫是在何時發生的呢?Lazy Writer和CheckPoint上面提到，SQL Server修改數據的步驟中並沒有包含將數據實際寫入到磁碟的過程.實際上，將緩沖區內的頁寫入到磁碟是通過兩個過程中的一個實現：這兩個過程分別為:1.CheckPoint2.Lazy Writer任何在緩沖區被修改的頁都會被標記為「臟」頁。將這個臟頁寫入到數據磁碟就是CheckPoint或者Lazy Writer的工作.當事務遇到Commit時，僅僅是將緩沖區的所有日誌頁寫入磁碟中的日誌文件:而直到Lazy Writer或CheckPoint時，才真正將緩沖區的數據頁寫入磁碟文件:前面說過，日誌文件中的LSN號是可以比較的，如果LSN2>LSN1,則說明LSN2的發生時間晚於LSN1的發生時間。CheckPoint或Lazy Writer通過將日誌文件末尾的LSN號和緩沖區中數據文件的LSN進行對比，只有緩沖區內LSN號小於日誌文件末尾的LSN號的數據才會被寫入到磁碟中的資料庫。因此確保了WAL（在數據寫入到資料庫之前，先寫入日誌)。Lazy Writer和CheckPoint的區別Lazy Writer和CheckPoint往往容易混淆。因為Lazy Writer和CheckPoint都是將緩沖區內的「臟」頁寫入到磁碟文件當中。但這也僅僅是他們唯一的相同點了。Lazy Writer存在的目的是對緩沖區進行管理。當緩沖區達到某一臨界值時，Lazy Writer會將緩沖區內的臟頁存入磁碟文件中，而將未修改的頁釋放並回收資源。而CheckPoint存在的意義是減少伺服器的恢復時間(Recovery Time).CheckPoint就像他的名字指示的那樣，是一個存檔點.CheckPoint會定期發生.來將緩沖區內的「臟」頁寫入磁碟。但不像Lazy Writer,Checkpoint對SQL Server的內存管理毫無興趣。所以CheckPoint也就意味著在這個點之前的所有修改都已經保存到了磁碟.這里要注意的是：CheckPoint會將所有緩沖區的臟頁寫入磁碟，不管臟頁中的數據是否已經Commit。這意味著有可能已經寫入磁碟的「臟頁」會在之後回滾（RollBack).不過不用擔心，如果數據回滾，SQL Server會將緩沖區內的頁再次修改，並寫入磁碟。通過CheckPoint的運作機制可以看出，CheckPoint的間歇(Recovery Interval)長短有可能會對性能產生影響。這個CheckPoint的間歇是一個伺服器級別的參數。可以通過sp_config進行配置，也可以在SSMS中進行配置:恢復間歇的默認參數是0，意味著由SQL Server來管理這個回復間隔。而自己設置恢復間隔也是需要根據具體情況來進行界定。