資料庫管理

前言在進行資料庫開發與維護時，經常需要知道資料表、檢視表或預存程序最後的修改時間。這些資訊在追蹤系統變更、問題排除、版本控制時都用得上。本文介紹幾個實用的 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 Server 的目錄檢視，涵蓋使用者物件（sys.objects）...

問題情境資料庫裡有個代碼欄位 MaintainClassID，散落在幾十張資料表中。要把值 4851204 全部改成 4851206，逐張查、逐張改——這不只費時，還容易漏掉某張表。 有沒有辦法讓 SQL Server 自己列出所有含這個欄位的資料表，再批量產生 UPDATE 語句？有。 解決方案INFORMATION_SCHEMA.COLUMNS 視圖記錄了目前資料庫所有欄位的中繼資料，查一次就能得到所有包含目標欄位的資料表清單。 步驟一：找出所有包含特定欄位的資料表12345678910111213-- 找到所有有該欄位的資料表SELECT DISTINCT t.TABLE_SCHEMA, -- 資料表的結構描述名稱 t.TABLE_NAME -- 資料表名稱FROM INFORMATION_SCHEMA.COLUMNS c INNER JOIN INFORMATION_SCHEMA.TABLES t ON c.TABLE_NAME = t.TABLE_NAME AND c.TABLE_SCHEMA = t.TA...

前言身為後端工程師，你是否遇過這樣的情況： 系統突然變得超級慢 網頁一直轉圈圈 收到「已超過連線逾時的設定」錯誤訊息 如果有，很可能就是連線池爆掉了。以下分享一個真實案例，從診斷、緊急處理到根治。 問題診斷當你遇到以下錯誤訊息時，很可能是連線池出問題了： 1System.InvalidOperationException: '已超過連線逾時的設定。在取得集區連線之前超過逾時等待的時間，可能的原因為所有的共用連線已在使用中，並已達共用集區大小的最大值。' 快速診斷方法首先，用以下 SQL 查看目前的連線狀況。sys.sysprocesses 是 SQL Server 2000 相容性視圖，SQL Server 2005 起已標記 deprecated，這裡改用官方建議的 DMV： 123456789101112-- 各資料庫連線數摘要（依登入帳號、狀態分組）SELECT DB_NAME(s.database_id) AS DatabaseName, COUNT(*) AS NumberOfConnections...

SQL Server 的備份檔，這個月又比上個月大了好幾 GB。打開資料庫一看，資料表筆數沒什麼變，那這些空間是哪來的？ 很多人第一反應是「資料庫膨脹了」，然後跑去 DBCC SHRINKDATABASE 想把它壓回來。先停手——SHRINK 是 SQL Server 裡最容易幫倒忙的指令之一，後面會講為什麼。先搞懂備份檔為什麼會長大。 完整備份複製的是資料庫裡「已配置的資料頁」加上一小段交易記錄，不是 mdf 檔的實體大小。一個 100 GB 的 mdf，裡面只有 40 GB 的頁真有資料，備份檔大約就是 40 GB 出頭。所以備份檔變大，意思是已配置的頁變多了——或者，根本不是資料庫的問題，是備份檔本身在累積。順這條線，由最常見往下查。 真因一：你每天往同一個檔案疊備份（最常見）頭號元兇，也最容易被忽略。BACKUP DATABASE 不指定 WITH INIT 時，預設是 NOINIT——把這次備份附加到既有檔案，不是覆蓋。 如果排程固定備份到 D:\Backup\MyDB.bak、每天跑又沒寫 INIT，這個檔案裡其實疊了一份又一份完整備份，當然每天長大。 要確認是不是這...