2015年1月12日 星期一

MVA學習筆記:SQL Server管理入門(二)

MVA連結

SQL交易記錄概觀:

交易流程:


  • 應用程式輸入資料變更=>在buffer cache找到或載入資料頁修改資料=>變更被記錄在交易記錄(ldf)=>checkpoint將dirty pages更新到資料檔

復原模式應用:


  • 簡單

  • 無法使用交易記錄備份
  • 自動清除交易記錄讓空間需求量最小

  • 完整

  • 管理資料庫需要交易記錄備份
  • 減少資料檔損毀造成的損失
  • 可以回復到特定時間點

  • 大量記錄

  • 管理資料庫需要交易記錄備份
  • 一般可提升bulk copy的行為效能
  • 針對一些bulk操作可因最小記錄而減少交易記錄使用的空間

備份策略:


  • 可容納的資料損失?
  • 使用何種備份類型?
  • 誰來執行?
  • 誰來規劃?
  • 頻率為何?
  • 多久做一次還原測試?
  • 是否搭配協助廠商工具?
  • 使用何種備份媒體? 

SQL SERVER備份類型:

  • 完整-所有檔案和部份交易記錄
  • 備份完整的資料庫
  • 備份交易記錄檔作用中(active)的部份,以回復資料庫
  • SQL2008之後提供了備份壓縮功能,不過針對沒有壓縮率的資料就不需要特別使用

  • 差異-上次完整之後有變更的資料庫資料

  • 備份前一次完整資料備份之後有變更的extents
  • 備份交易記錄檔作用中(active)的部份,以回復資料庫
  • 差異備份間彼此無關

  • 部份-primary檔案群組,每個讀/寫檔案群組,以及特定的唯讀檔案群組

  • 交易記錄-在ldf內記錄的任何資料庫變更

  • 僅備份交易記錄
  • 備份從最後一次成功的交易記錄備份到當下的記錄結尾

  • 備份交易記錄結尾-在還原之前備份交易記錄的結尾記錄

  • 如果mdf、ndf都已損毀,但ldf沒有損壞,可以利用此備份,在做還原之後再將所有交易記錄還原。 
  •  在循序還原之前用來擷取交易記錄的結尾,等同執行一次一般的記錄備份。
  • 當接下來就要開始還原,可使用norecovery(將資料庫狀態改為recovering)
  • 當資料檔遺失或損毀,但交易記錄檔仍完整,可使用continue_after_error 

  • 檔案/檔案群組-指定特定的檔案和檔案群組

  • 只複製備份-資料庫或交易記錄

  • 在兩個資料庫之後搬移資料從A拿去B,又不想破壞原來的備份還原順序使用
  • 只複製交易記錄備份不會清掉交易記錄
  • 只複製完整備份不會影響差異備份

確認備份完整性的選項:

  • 鏡像備份裝置
  • 備份集最多可以四份(企業版支援)
  • 總和檢查碼(checksum)備份選項
  • 驗證備份(restore verifyonly),搭配checksum選項較為有用

檢視備份資料:

  • SQLSERVER透過msdb資料庫一組資料表追縱所有的備份作業
  • 還原的時候SQLSERVER UI會根據你的備份來建議你做最佳還原方式
  • 可以從備份媒體取得資訊
  • RESTORE LABELONLY傳回含有給定備份裝置所識別的備份媒體之相關資訊的結果集
  • RESTORE HEADERONLY傳回含有特定備份裝置上的所有備份組之所有備份標題資訊的結果集
  • RESTORE FILELISTONLY傳回含有資料庫清單的結果集及備份組所包含的記錄檔

備份考量:

  • 備份是線上同時進行,不限制使用者存取,可能因為I/O負係低其它作業效能
  • 一般備份時使用CPU約10%以內的資源,但有啟用壓縮時會拉高使用率
  • 一般備份作業時,資料庫需處理上線狀態
  • 當資料庫損毀時仍可以執行交易記錄備份
  • 交易記錄檔必需是完整的

還原類型:


  • 簡單模式
  • 完整模式
  • 還原系統資料庫
  • 僅還原受損檔案
  • 進階的還原選項,包含online、piecemeal、page還原

準備還原備份:


  • 可能需要執行結尾記錄備份(只適用大量記錄和完整)
  • 確認要還原的備份內容

還原流程的階段:

  • SQLSERVER資料庫的回復流程分三階段
  • 分析與資料複製:建立檔案並複製資料到檔案內,分REDO和UNDO
  • REDO:從還原的記錄將交易結果更新到資料檔
  • UNDO:在還原的當下,將未完成的交易回復
  • REDO和UNDO稱為RECOVERY

WITH RECOVERY選項:

  • 資料庫必須要完成還原才能上線使用
  • WITH NORECOVERY還原選項保持資料庫正在還原狀態,允許對資料庫執行額外的還原作業。

WITH STANDBY選項:

  • 可以唯讀的方式查詢未還原的資料庫,透過待命資料庫檔案存放UNDO階段的細節資料。
  • 建立待命伺服器提供資料的唯讀查詢
  • 在多個交易記錄回復之間查閱資料庫
  • 在人為災難時非常好用

回復到特定時間點:

  • 讓資料庫可以回到特定的時間點,相關記錄都存在交易記錄備份中
  • 定義特定時間點的方式,透過交易名稱標記
  • 資料庫最好是完整復原
  • 交易記錄若包含大量記錄,回復的特定時間點剛好落在大量記錄復原模式的最小記錄行為區段,將導致回復失敗。
  • restore log xx from disk='xx' with standby='xx' ,stopat='時間點'

資料的移轉:

  • ETL:EXTRACT TRANSFORM LOAD
  • 在伺服器間複製或搬移資料
  • 將查詢的資料輸出成檔案
  • 從檔案將資料載入資料表
  • 從檢視讀取或輸入資料
  • 轉換定序或BIG5轉UNICODE

資料轉換可用的工具:

  • BULK COPY PROGRAM(BCP)
  • BULK INSERT
  • OPENROWSET(BULK)
  • IMPORT/EXPORT WIZARD(SSIS)
  • XML BULK LOAD

強化資料轉換效能:

  • 停用條件約束、索引和觸發
  • 減少鎖定,考慮使用TABLOCK以加速載入
  • 在目的端透過SELECT INTO會比從來源端做來的有效率
  • 減少交易記錄,採BULK MODE或是SIMPLE MODE
  • 減少資料轉換,採用NATIVE格式
  • 來源跟目的皆為SQLSERVER的話採NATIVE模式效率好
  • LOCK量會從ROWLOCK到PAGELOCK再到TABLOCK
  • SQL SERVER INTEGRATION SERVICES 概觀(SSIS):
  • 提供開發ETL解決方案豐富的架構

SSIS封裝包含:

  • 資料來源和目的
  • 控制和資料流程
  • 各種不同的轉換
  • 可執行SSIS封裝的方式
  • DTEXECUI和DETEXC命令列工具
  • SQLSERVER AGENT作業
  • 開發SSIS封裝的方式
  • SSDT
  • 匯入/匯出精靈

BCP:

  • 直接在CMD處執行命令
  • 中介的通常是一個檔案
  • 產生格式檔
  • bcp Northwind.dbo.customers format nul -T -c -x -f Cust.xml
  • 匯出
  • bcp Northwind.dbo.customers out "e:\temp\Cust.dat" -T -c
  • 匯入
  • bcp tempdb.dbo.customers in Cust.dat -T -f Cust.xml

BULK INSERT語法:

  • 提供與BCP近似的選項
  • 執行在SQLSERVER應用程式內
  • 有CHECK_CONSTRAINTS和FIRE_TRIGGERS選項

MVA學習筆記:SQL Server管理入門(一)

MVA連結

硬體需求:


  • 就愈高級愈好=..=

軟體需求:


  • 避免安裝在DOMAIN CONTROLLER
  • 建議安裝在64位元的作業系統
  • .NET FRAMEWORK 3.5 AND 4

決定檔案存放位置:

  • 透過壓力測試來決定硬碟數量
  • 硬碟分頁大小建議設定64k
  • 收交易記錄檔和資料檔案放在不同的實體位置上
  • 使用適當的RAID設定
  • DATAFILE、mdf、ndf一般採RAID5
  • 基於效能和維護來決定檔案的數量和位置
  • 確定交易記錄需求(ldf檔)
  • 一般是放RAID1
  • 交易記錄一般只需要一個,因為交易記錄是循序寫入

服務帳號:

  • 獨立建立服務帳號
  • 在SQLSERVER安裝時所賦予的帳號,或是透過SQLSERVER組態管理員設定的帳號,會自動賦予所需的權限

設定定序:

  • 決定文字間的大於、等於、等於
  • WINDOWS定序與WINDOWS的規則相同
  • SQL定序與早期的SQLSERVER用法相同
  • 預設的定序
  • 跨國企業的定序建議以英文定序設定

SQLSERVER資料存放:

  • 主要資料檔案-.mdf
  • 次要資料檔案-.ndf
  • 交易記錄檔案-.ldf
  • 資料表跟索引存放在資料頁,並以Extent群組管理
  • Extent:8個連續的8kb資料頁
  • 資料與LOG會設計存放在不同硬碟上面

確定足夠的檔案容量:

  • 估計資料、交易記錄和tempdb的容量
  • 系統資料庫只有一個tempdb,但所有database都會共享它,所以要放在讀取快速的I/O上,如SSD
  • 設定合理的大小
  • 賦予新增資料足夠的大小,不要經常擴增
  • 監控資料和交易記錄檔的使用
  • 手動擴增計劃
  • 允許自動增長,以防不預期的需求

Tempdb:

  • 存放內部物件的暫存資料、記錄版本、使用者物件
  • 執行個體重起的時候會重建
  • 依SQLSERVER執行個體的使用方式與負載會佔用不同大小的空間
  • 需要依靠真實的負載來測試
  • 放到獨立而快速的I/O子系統確保效能
  • 為其建立與實體CPU等量等大的檔案數(最多8個資料檔)
  • 透過測試確認最佳的值

擴增和縮小資料庫檔案:

  • 可以手動變動
  • 可以自動擴增,但應該避免,應計劃手動擴增
  • 可以縮小檔案,DBCC SHRINKDATABASE...易造成資料庫擺放資料破碎


2015年1月7日 星期三

MVA學習筆記:SQLServer例行管理

MVA連結

每日檢核項目:

檢核記錄檔:


  • SQLServer錯誤記錄檔
  • WindowsServer事件檢視器
  • 硬體異常記錄
  • 排程作業是否正常
  • 效能記錄檔
  • 是否raid硬碟故障

每週檢核項目:

確認備份檔案可用性


作業系統、SQLServer、應用程式更新

SQLServer Management Studio報表

資料庫交易記錄檔是否異常成長

每月檢核項目:

  • 執行備份還原演練
  • 變更管理
  • DBCC檢查
  • 容量規劃/基準比較
  • 健全狀況
  • 改善計劃

可利用SP快速查詢LOG

  • exec sp_readerrorlog
  • 參考連結
  • exec xp_readerrorlog
  • sp_readerrorlog的底層一樣是使用xp去作業,但多了一個權限的限制。
  • sp_cycle_errorlog-關閉目前記錄檔,重新開始。

可以利用Power Shell來取得LOG

  • # 取得在 2014-07-01 之後的事件檢視器內的 Application Event Log  
  • #get-eventlog -logname Application -After "2014-08-01"

  • # 只取 SQL Server 的訊息
  • #get-eventlog -logname Application -After "2014-08-01" -Source "MSSQLSERVER"

  • # 只取 SQL Server 的錯誤訊息 
  • get-eventlog -logname Application -After "2014-07-01" -Source "MSSQLSERVER"  -EntryType "Error"

  • # 存到 CSV 檔案內
  • get-eventlog -logname Application -After "2014-08-01" -EntryType "Error" -Source "MSSQLSERVER" |
  • export-csv -Path C:\TEST.csv -NoTypeInformation -Encoding "unicode"

軟硬體執行環境分析

  1. 電源管理:透過電源管理可以避免CPU自動降頻。
  2. 硬體效能:CRYSTALDISKMARK
  3. 效能監視器:轉出CSV之後透過分析表來分析。
  • 2008以前執行『performance monitor』
  • 2008之後在伺服器管理員的診斷\效能

索引維護

  • 只要對基礎資料進行CURD作業,SQLSERVER會自動維護索引,但過一段時間之後,這些修改就可能使索引中的資訊變成散佈於資料庫中,當根據索引鍵值的邏輯順序頁面與資料檔中的實體順序不相符時,就會有片段產生。
  • 片段嚴重的索引可能會造成查詢效能降低並使回應變慢。
  • sys.dm_db_index_physical_stats取得相關資訊。
SELECT
OBJECT_NAME(s.object_id) tablename, i.name indexname,
index_type_desc,index_level, avg_fragmentation_in_percent,avg_page_space_used_in_percent, page_count

FROM sys.dm_db_index_physical_stats(DB_ID(N‘資料庫名稱'), NULL, NULL, NULL , 'SAMPLED') s
JOIN sys.indexes i ON s.object_id = i.object_id and s.index_id = i.index_id
ORDER BY avg_fragmentation_in_percent DESC

  • 利用維護計劃來做索引維護
  • 可以透過指令來針對部份TABLE做索引重建
  • 透過報表可以看索引實體統計資料瞭解索引狀況。
  • Fragmentation>30,建議重建索引。5~30選擇重新組織索引。
  • 重建索引時,索引保留在線上<-這功能只有在Enterprise版本才有支援。