SQL Server

前言隨著資安事件頻傳,如何保護資料庫中的敏感資料成為當前的重要課題。Microsoft SQL Server提供的透明資料加密(Transparent Data Encryption, TDE)是一個強大的解決方案,它能夠在資料寫入磁碟時自動加密,讀取時自動解密,對應用程式完全透明。本文將帶您一步步實作TDE,並深入探討其運作原理。 TDE運作原理TDE的主要目的是保護資料庫檔案(.mdf、.ldf)中的靜態資料。當資料要寫入磁碟時,TDE會自動進行加密;當需要讀取資料時,則會自動解密。整個過程對應用程式來說是完全透明的,不需要修改任何程式碼。 以下是TDE的運作流程: 資料庫檔案 資料庫引擎 記憶體 資料庫加密金鑰 憑證 加密 ...

前言每個資料庫管理員都曾遇過這種情況：老闆說「我要這個報表，越快越好」，結果你發現要匯出的資料有好幾億筆... 別擔心！本篇文章將完整介紹SQL Server三大CSV匯出工具：SQLCMD、BCP和SSIS的實戰技巧。透過實際案例分析和效能測試，教你如何選擇最適合的工具，並運用最佳化技巧大幅提升匯出效能！ 三大工具特色比較 SQLCMD 優點：彈性高、容易整合自動化流程、指令碼管理方便 缺點：需要撰寫較多程式碼 適用場景：自動化排程作業、需要客製化處理的匯出工作 BCP (Bulk Copy Program) 優點：效能最佳、記憶體使用率低、適合大量資料處理 缺點：彈性較低、特殊資料處理較複雜 適用場景：大量資料快速匯出、簡單資料結構 SSIS (SQL Server Integration Services) 優點：視覺化設計、功能完整、整合性高 缺點：設定複雜、維護成本較高 適用場景：複雜ETL流程、需要資料轉換處理 SQL Server CSV匯出工具完整比較 SQLCMD 優點: - 彈性高 -...

前言在進行資料庫開發與維護時，經常需要知道資料表、檢視表或預存程序最後的修改時間。這些資訊對於： 追蹤系統變更 問題排除 效能調校 版本控制都非常重要。本文將介紹幾個實用的SQL查詢技巧，讓你輕鬆掌握資料庫物件的時間資訊。 查詢資料表與檢視表的修改時間以下是查詢資料表與檢視表修改時間的SQL： 12345678SELECT [name] -- 物件名稱 ,create_date -- 建立時間 ,modify_date -- 修改時間 ,type_desc -- 物件類型FROM sys.all_objects WHERE type_desc = 'USER_TABLE' -- 使用者資料表 OR type_desc = 'VIEW' -- 檢視表ORDER BY modify_date DESC -- 依修改時間排序 查詢說明 sys.all_objects: SQL...

前言在管理大型SQL Server資料庫時,你是否遇過以下痛點？ 資料匯入匯出緩慢到讓人抓狂 維護作業需要人工執行,常常加班到半夜 大型資料庫備份還原總是出問題 跨伺服器操作複雜又容易出錯 別擔心！本篇完整剖析SQLCMD的所有實戰技巧,讓你輕鬆應對各種資料庫維運挑戰。無論你是資深DBA還是新手工程師,都能從中學到實用的技巧！ SQLCMD 功能與效能概觀 SQLCMD 資料匯入匯出 批次處理優化 執行SQL指令 效能監控 資料庫備份 壓縮優化 自動化排程 錯誤處理 大型資料庫匯入效能比較 一般匯入 批次處理 最佳化設定 實戰經驗分享案例一：10TB...

前言在管理大型SQL Server資料庫時,SQLCMD是一個不可或缺的命令列工具。無論是執行日常維護工作、資料匯入匯出,還是建立自動化作業,SQLCMD都能幫助我們更有效率地完成這些任務。本文將詳細介紹SQLCMD的各種應用方式,幫助你掌握這個強大的工具。 SQLCMD 功能概觀 SQLCMD 資料匯入匯出 執行SQL指令 資料庫備份 自動化排程 SQLCMD基本語法SQLCMD的基本語法結構如下： 12345678sqlcmd -S <伺服器名稱> -- 指定SQL Server執行個體-U <使用者名稱> -- 指定登入帳號-P <密碼> -- 指定密碼-d <資料庫名稱> -- 指定要使用的資料庫-i <輸入檔案> -- 指定要執行的SQL指令檔-o...

前言在管理資料庫時，我們經常會遇到需要在多個資料表中更新相同欄位的情況。例如：修改某個代碼、更新狀態值等。如果要手動找出所有包含該欄位的資料表並逐一更新，不只費時還容易出錯。今天就來分享一個實用的 SQL 技巧，教你如何快速找出並更新特定欄位！ 使用情境假設我們需要將所有資料表中的 MaintainClassID 欄位從 4851204 更新為 4851206。在大型資料庫中，這個欄位可能分散在多個資料表中。如何一次找出所有包含此欄位的資料表呢？ 解決方案我們可以利用 SQL Server 的 INFORMATION_SCHEMA 視圖來查詢資料庫結構，並產生所需的更新語句。讓我們一步步來看： 步驟一：找出所有包含特定欄位的資料表12345678910111213-- 找到所有有該欄位的資料表SELECT DISTINCT t.TABLE_SCHEMA, -- 資料表的架構名稱 t.TABLE_NAME -- 資料表名稱FROM INFORMATION_SCHEMA.COLUMNS c INNER JOIN ...

前言在處理大型資料庫時，有時候我們需要將一個大型資料表的資料分割成多個較小的資料表，以提升查詢效能或方便資料管理。本文將介紹如何使用SQL Server的SELECT INTO搭配批次處理來實現這個目標。 SELECT INTO 的神奇魔力SELECT INTO 是SQL Server提供的一個強大功能，它可以： 根據查詢結果直接建立新的資料表 自動複製資料表結構 自動將資料寫入新表 來源資料表 批次處理邏輯 每批500筆資料 資料表1 資料表2 資料表3 資料表4 資料表... 讀取原始資料 依據ROW_NUMBER()分批建立新資料表 程式碼詳解讓我們來看看完整的程式碼： 1234567891011121314151617181920212223242526272829303132333435-- 宣告必要的變數DECLARE @StartRow INT, --...

前言最近在處理資安弱點掃描時，常常收到建議「關閉 TLS 1.1 和 TLS 1.2，只開啟 TLS 1.3」的要求。這個改動看似簡單，但實際執行時可能會遇到很多意想不到的問題。本文將分享實戰經驗，幫助大家順利完成升級。 為什麼要升級到 TLS 1.3？資安考量 TLS 1.3 提供更強的加密演算法 移除了舊版本中不安全的加密方式 改善了握手過程的安全性 法規要求 新版 PCI DSS 要求使用 TLS 1.3 資安弱點掃描工具會標記較舊版本為風險 符合最新的安全標準 可能遇到的問題1. 遠端桌面連線 (RDP) 問題 Windows Server 2016 之前的版本可能無法連線 需要安裝更新才能支援 TLS 1.3 舊版 RDP 客戶端可能完全無法使用 2. SQL Server 連線問題 SQL Server 2016 之前的版本預設不支援 TLS 1.3 連線字串可能需要調整 某些舊版管理工具可能無法連線 3. 應用程式相容性 部分舊版 .NET Framework 應用程式可能無法運作 Java 8 之前的版本不支援 TLS...

前言身為後端工程師，你是否遇過這樣的情況： 系統突然變得超級慢 網頁一直轉圈圈 收到「已超過連線逾時的設定」錯誤訊息 如果有，恭喜你！你可能遇到了資料庫連線池爆掉的問題。今天就來分享一個真實案例，看看如何從診斷到解決這個棘手的問題。 問題診斷當你遇到以下錯誤訊息時，很可能是連線池出問題了： 1System.InvalidOperationException: '已超過連線逾時的設定。在取得集區連線之前超過逾時等待的時間，可能的原因為所有的共用連線已在使用中，並已達共用集區大小的最大值。' 快速診斷方法首先，我們可以使用以下 SQL 指令來查看目前的連線狀況： 12345678910SELECT DB_NAME(dbid) as DatabaseName, COUNT(dbid) as NumberOfConnections, loginame as LoginName, status, hostname as HostName, program_name as ProgramNameFROM...

Redis詳細介紹、使用場景及與SQL Server的結合什麼是Redis?Redis(Remote Dictionary Server)是一個開源的、高性能的、基於記憶體的鍵值對數據庫。它由Salvatore Sanfilippo開發,並於2009年首次發布。Redis不僅僅是一個簡單的鍵值存儲,它還支持多種數據結構,如字符串、哈希、列表、集合、有序集合等。 Redis的主要特點 高性能: Redis將所有數據存儲在記憶體中,因此可以實現極快的讀寫速度。 持久化: 儘管是記憶體數據庫,Redis也提供了數據持久化的選項。 多種數據結構: 支持字符串、哈希、列表、集合、有序集合等數據類型。 原子性操作: Redis的所有操作都是原子性的,包括那些處理複雜數據結構的操作。 多功能性: 除了作為數據庫使用,Redis還可用作緩存、消息隊列等。 支持事務: Redis支持事務,可以一次執行多個命令。 發布/訂閱功能: 實現了發布/訂閱模式,可用於消息傳遞。 Redis的使用場景Redis因其高性能和多功能性,在多種場景下都有廣泛應用。以下是一些常見的使用場景: 1....