SQL SERVER 如果在執行計畫要查看 實際資料列數目(Actual Number of Rows) 須把Include Actual Execution Plan 勾選 ,這樣才會看的到,
不然若只是 run Display Estimated Execution Plan不會顯示Actual Number of Rows.
2015年4月2日 星期四
2015年1月6日 星期二
SQL Server Operating system error 5: “5(Access is denied.)”
This is Windows related problem where SQL Server does not have appropriate permission to the folder which contains .bak file. The easiest work around that I found was to copy your .bak to default SQL backup location which has all the necessary permissions. You do not need to fiddle with anything. In SQL SERVER 2012, this location is
C:\Program Files\Microsoft SQL Server\MSSQL11.BI\MSSQL\DATA
"MSSQL11.BI" BI是我取的SQL SERVER 名子
預設位置如下
D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA
把檔案放在此位置 ,在databases按右鍵選擇 Attach 就沒出現問題了
also cna use this script
CREATE DATABASE AdventureWorks2008R2 ON (FILENAME = 'C:\reports\AdventureWorks2008R2_Database\AdventureWorks2008R2_Data.mdf'),
(FILENAME = 'C:\reports\AdventureWorks2008R2_Database\AdventureWorks2008R2_log.ldf') FOR ATTACH;
C:\Program Files\Microsoft SQL Server\MSSQL11.BI\MSSQL\DATA
"MSSQL11.BI" BI是我取的SQL SERVER 名子
預設位置如下
D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA
把檔案放在此位置 ,在databases按右鍵選擇 Attach 就沒出現問題了
also cna use this script
CREATE DATABASE AdventureWorks2008R2 ON (FILENAME = 'C:\reports\AdventureWorks2008R2_Database\AdventureWorks2008R2_Data.mdf'),
(FILENAME = 'C:\reports\AdventureWorks2008R2_Database\AdventureWorks2008R2_log.ldf') FOR ATTACH;
2013年10月30日 星期三
transaction log file是採用循環使用的,當最後一個 virtual log file用完之後便會從檔案開頭繼續重複使用,所以通常檔案是固定大小不會成長的,只有遇到如交易量太大或某交易遲遲未commit,才會讓transaction log file長大,SQL Server裡面也有 MinLSN 的概念,只有MinLSN之前的 virtual log files空間才能被重複使用,這時就會依照所設定的growth_increment來自動成長,只要目錄空間夠的話。
SQL Server recovery model的設定跟 transaction log有很大的關聯,有3種model
1. Simple recovery model
2. Full recovery model
3. bulk-logged recovery model
Simple recovery model 方式就像 DB2 circular logging,完全不需管理,採循環使用方式,當checkpoint時會自動 truncate logs,但是只支援將資料庫復原到備份當時。
Full recovery model和 bulk-logged recovery model就類似 DB2 linear logging,checkpoint時 virtual logs並不會自動truncate,必須備份 log 之後才會truncate,可以支援 point-in-time recovery。
Full recovery model和 bulk-logged recovery model的差別在於執行某些可以被minimally logged的動作時,在Full recovery model中所有的動作都會被記錄下來,而在bulk-logged recovery model中只記錄重點可回復該動作的部分,且不支援point-in-time的復原。所以會加速該動作的執行,但是最後log record會比較大,因為會紀錄該動作的結果。
有關bulk-logged recovery model這部分的理解,很像是 DB2 在執行 LOAD 動作,過程僅產生很少的log record,所以速度比 IMPORT快,而為了資料庫的復原要求,需要將LOAD進資料庫的資料進行備份,而SQL Server就將該minimally logged動作的結果放在 transaction logs裡面。
因此SQL Server建議一般採用 Full Recovery Model,當有需要執行會產生大量交易的動作時,先切換到 Bulk-logged recovery model,完成後再切換回來,以加快速度。而在Bulk-logged recovery model期間是不支援 point-in-time recovery,所以最好在之前與之後各做一次LOG備份。
SQL Server recovery model的設定跟 transaction log有很大的關聯,有3種model
1. Simple recovery model
2. Full recovery model
3. bulk-logged recovery model
Simple recovery model 方式就像 DB2 circular logging,完全不需管理,採循環使用方式,當checkpoint時會自動 truncate logs,但是只支援將資料庫復原到備份當時。
Full recovery model和 bulk-logged recovery model就類似 DB2 linear logging,checkpoint時 virtual logs並不會自動truncate,必須備份 log 之後才會truncate,可以支援 point-in-time recovery。
Full recovery model和 bulk-logged recovery model的差別在於執行某些可以被minimally logged的動作時,在Full recovery model中所有的動作都會被記錄下來,而在bulk-logged recovery model中只記錄重點可回復該動作的部分,且不支援point-in-time的復原。所以會加速該動作的執行,但是最後log record會比較大,因為會紀錄該動作的結果。
有關bulk-logged recovery model這部分的理解,很像是 DB2 在執行 LOAD 動作,過程僅產生很少的log record,所以速度比 IMPORT快,而為了資料庫的復原要求,需要將LOAD進資料庫的資料進行備份,而SQL Server就將該minimally logged動作的結果放在 transaction logs裡面。
因此SQL Server建議一般採用 Full Recovery Model,當有需要執行會產生大量交易的動作時,先切換到 Bulk-logged recovery model,完成後再切換回來,以加快速度。而在Bulk-logged recovery model期間是不支援 point-in-time recovery,所以最好在之前與之後各做一次LOG備份。
訂閱:
文章 (Atom)
