SQL Server收縮資料庫

官網：

https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-2017

Exec sp_spaceused;
 
 
ALTER DATABASE HKMNewsDB MODIFY FILE ( NAME = N'HKMNewsDB', SIZE = 310390MB );
 
DBCC SHRINKDATABASE(tempdb,1) ;
DBCC SHRINKFILE(1,TRUNCATEONLY);
DBCC SHRINKFILE(1,238238);
 
 
select * from sys.database_files;
 
 
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

1.1   不能收縮 ID 為 %s 的資料庫中 ID 為 %s 的檔案，因為它正由其他程式收縮或為空

SQLServer 資料庫通常都不建議進行 SHRINKFILE 操作，因為 SHRINKFILE 不當會造成一定的效能問題。

但是當進行了某些操作 ( 例如某個超大的日誌型別錶轉成分割槽表切換了資料檔案 ) ，資料庫某個檔案組中的剩餘空間佔了整個磁碟的很大一部分，而且磁碟空間已經吃緊的情況下，你也許會考慮收縮一下某個資料檔案。

收縮資料檔案時，可以每次收縮一點點（例如每次 5GB ）來進行。

然而博主最近對某個資料庫進行資料庫收縮時碰到了標題所示的困擾。在 DBCC SHRINKFILE (db_name , target_size) 執行了幾次之後。

DBCC SHRINKFILE (db_name , target_size)

莫名出現瞭如下錯誤：

不能收縮 ID 為 6 的資料庫中 ID 為 1 的檔案，因為它正由其他程式收縮或為空。

據網上的經驗，備份之後仍然不變，重啟也無效，嘗試重建某些表的索引，也無效。

但博主在嘗試將資料庫檔案增加 10MB ，然後再次收縮資料庫的時候這個錯誤消失了。

ALTER DATABASE db_name MODIFY FILE ( NAME = file_name, SIZE = target_size )

後來從官方社群找到了答案：應該是我在進行 DBCC SHRINKFILE 的時候正好同時進行了備份操作（定時日誌備份）。

官方給的解決方法就是將要收縮的資料檔案增加一點點，哪怕 1MB 。

 

參考相關文件：

https://msdn.microsoft.com/zh-cn/library/ms189493.aspx

DBCC SHRINKDATABASE (Transact-SQL)

• 
  

語法

SQL 複製

DBCC SHRINKDATABASE    ( database_name | database_id | 0         [ , target_percent ]         [ , { NOTRUNCATE | TRUNCATEONLY } ]    )   [ WITH NO_INFOMSGS ]

引數

database_name  |  database_id  | 0
要收縮的資料庫名稱或 ID。   0 指定使用當前資料庫。

target_percent
資料庫收縮後的資料庫檔案中所需的剩餘可用空間百分比。

NOTRUNCATE
將分配的頁面從檔案的末尾移動到檔案前面的未分配頁面。   此操作會壓縮檔案中的資料。   target_percent  是可選的。   Azure SQL 資料倉儲不支援此選項。

檔案末尾的可用空間不會返回給作業系統，並且檔案的物理大小也不會更改。   因此，指定 NOTRUNCATE 時，資料庫似乎不會收縮。

NOTRUNCATE 只適用於資料檔案。   NONTRUNCATE 不會影響日誌檔案。

TRUNCATEONLY
將檔案末尾的所有可用空間釋放給作業系統。   不移動檔案內的任何頁面。   資料檔案僅收縮到最後指定的盤區。 如果使用 TRUNCATEONLY 指定，則會忽略  target_percent 。   Azure SQL 資料倉儲不支援此選項。

TRUNCATEONLY 將影響日誌檔案。   若要僅截斷資料檔案，請使用 DBCC SHRINKFILE。

WITH NO_INFOMSGS
取消嚴重級別從 0 到 10 的所有資訊性訊息。

結果集

下表對結果集中的列進行了說明。

列名	描述
DbId	資料庫引擎 試圖收縮的檔案的資料庫標識號。
FileId	資料庫引擎 嘗試收縮的檔案的檔案標識號。
CurrentSize	檔案當前佔用的 8 KB 頁數。
MinimumSize	檔案最低可以佔用的 8 KB 頁數。   此值與檔案的最小大小或最初建立時的大小相對應。
UsedPages	檔案當前使用的 8 KB 頁數。
EstimatedPages	資料庫引擎 估計檔案能夠收縮到的 8 KB 頁數。

 備註

資料庫引擎 不顯示未收縮的檔案的行。

Remarks

 備註

當前，Azure SQL 資料倉儲不支援 DBCC SHRINKDATABASE。   不建議執行此命令，因為這是 I/O 密集型操作，可能會使資料倉儲離線。   此外，執行此命令後，還會對資料倉儲快照產生成本影響。

若要收縮特定資料庫的所有資料和日誌檔案，請執行 DBCC SHRINKDATABASE 命令。   若要一次收縮一個特定資料庫中的一個資料或日誌檔案，請執行  DBCC SHRINKFILE  命令。

若要檢視資料庫中當前的可用（未分配）空間量，請執行  sp_spaceused 。

可在程式中的任一點停止 DBCC SHRINKDATABASE 操作，任何已完成的工作都將保留。

資料庫不能小於配置的資料庫最小大小。   在最初建立資料庫時指定最小大小。   或者，最小大小可以是使用檔案大小更改操作顯式設定的最後大小。   DBCC SHRINKFILE 或 ALTER DATABASE 等操作是檔案大小更改操作的示例。

假設最初建立的資料庫大小為 10 MB。   然後，它增長到 100 MB。   即使資料庫中的所有資料都已刪除，資料庫可以減少到的最小大小也為 10 MB。

執行 DBCC SHRINKDATABASE 時，請指定 NOTRUNCATE 選項或 TRUNCATEONLY 選項。   如果不這樣做，結果與使用 NOTRUNCATE 執行 DBCC SHRINKDATABASE 操作，然後再使用 TRUNCATEONLY 執行 DBCC SHRINKDATABASE 操作相同。

收縮資料庫不必處於單使用者模式。   其他使用者可以在資料庫收縮時在其中工作，包括系統資料庫。

備份資料庫時，無法收縮資料庫。   反之，也不能在資料庫執行收縮操作時備份資料庫。

DBCC SHRINKDATABASE 的工作原理

DBCC SHRINKDATABASE 以每個檔案為單位對資料檔案進行收縮。然而，DBCC SHRINKDATABASE 在對日誌檔案進行收縮時，它將視為所有的日誌檔案都存在於一個連續的日誌池中。   檔案始終從末尾開始收縮。

假設擁有幾個日誌檔案、一個資料檔案和一個名為  mydb  的資料庫。   資料檔案和日誌檔案分別是 10 MB，並且資料檔案包含 6 MB 資料。   資料庫引擎  計算每個檔案的目標大小。   此值是檔案要收縮到的大小。   如果使用  target_percent  指定 DBCC SHRINKDATABASE ，則  資料庫引擎  計算得出的目標大小為收縮後檔案中可用空間的  target_percent  數量。

例如，如果為收縮  mydb  將  target_percent  指定為 25，則  資料庫引擎  計算得出此檔案的目標大小為 8 MB（6 MB 資料加上 2 MB 可用空間）。   因此， 資料庫引擎  將資料檔案後 2 MB 中的所有資料移動到資料檔案前 8 MB 的任何可用空間中，然後對該檔案進行收縮。

假設 mydb 的資料檔案包含 7 MB 的資料。   將  target_percent  指定為 30，以允許將此資料檔案收縮到可用空間的 30%。   但是，將  target_percent  指定為 40 不會收縮資料檔案，因為  資料庫引擎  將檔案收縮到的大小不能小於資料當前佔用的空間大小。

還可以用另一種方法來思考此問題：40% 的所要求可用空間加上 70% 的整個資料檔案大小（10 MB 中的 7 MB）超過了 100%。   任何大於 30 的  target_size  都不會收縮資料檔案。   它不會收縮是因為所需的可用百分比加上資料檔案當前佔用的百分比大於 100%。

對於日誌檔案， 資料庫引擎  使用  target_percent  計算整個日誌的目標大小。   這就是為什麼  target_percent  是收縮操作後日志中的可用空間量的原因。   之後，整個日誌的目標大小轉換為每個日誌檔案的目標大小。

DBCC SHRINKDATABASE 嘗試立即將每個物理日誌檔案收縮到其目標大小。   假設邏輯日誌沒有任何部分位於超出日誌檔案目標大小的虛擬日誌中。   然後檔案成功截斷，DBCC SHRINKDATABASE 完成且沒有生成任何訊息。 但是，如果部分邏輯日誌位於超出目標大小的虛擬日誌中，則  資料庫引擎  將釋放盡可能多的空間，併發出一條資訊性訊息。   該訊息說明需要執行哪些操作來將邏輯日誌移出位於檔案末尾的虛擬日誌。   執行操作後，DBCC SHRINKDATABASE 可用於釋放剩餘空間。

日誌檔案只能收縮到虛擬日誌檔案邊界。   這就是為什麼不可能將日誌檔案收縮到小於虛擬日誌檔案大小的原因。   即使未在使用它也可能無法實現。   虛擬日誌檔案的大小在建立或擴充套件這些日誌檔案時由 資料庫引擎 動態選擇。

最佳實踐

當您計劃收縮資料庫時，請考慮以下資訊：

• 收縮操作在執行某個操作後最有效。   此操作會建立未使用的空間，例如截斷表或刪除表操作。
• 大多數資料庫都需要一些可用空間，以供常規日常操作使用。   可能會反覆收縮資料庫，並注意到資料庫大小再次增長。   這種增長表明常規操作需要使用收縮的空間。   在這種情況下，反覆收縮資料庫是一種無謂的操作。
• 收縮操作不保留資料庫中索引的碎片狀態，通常還會在一定程度上增加碎片。   此結果是不要反覆收縮資料庫的另一個原因。
• 除非有特定要求，否則不要將 AUTO_SHRINK 資料庫選項設定為 ON。

故障排除

收縮操作可能會被在 基於行版本控制的隔離級別 下執行的事務阻止。   例如，在執行 DBCC SHRINK DATABASE 操作時，正在基於行版本控制的隔離級別下執行大型刪除操作。   當這種情況發生時，收縮操作會等到刪除操作完成後再收縮檔案。   收縮操作在等待時，DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 操作會列印輸出資訊性訊息（對於 SHRINKDATABASE 為 5202，對於 SHRINKFILE 為 5203）。   此訊息在第一個小時內每五分鐘列印到  SQL Server  錯誤日誌一次，然後在後續每個小時列印一次。   例如，如果錯誤日誌包含以下錯誤訊息：

SQL 複製

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot    transaction with timestamp 15 and other snapshot transactions linked to    timestamp 15 or with timestamps older than 109 to finish.

此錯誤表示時間戳早於 109 的快照事務將阻止收縮操作。   該事務是收縮操作完成的最後一個事務。   它還說明  sys.dm_tran_active_snapshot_database_transactions (Transact-SQL)  動態管理檢視中的  transaction_sequence_num  或  first_snapshot_sequence_num  列包含值 15。   該檢視中的  transaction_sequence_num  或  first_snapshot_sequence_num  列可能包含小於收縮操作完成的最後一個事務 (109) 的數字。   如果是這樣，收縮操作將等待這些事務完成。

若要解決此問題，請執行下列任務之一：

• 終止阻止收縮操作的事務。
• 終止收縮操作。   所有已完成的工作都會保留。
• 不執行任何操作，並允許收縮操作等到阻塞事務完成。

許可權

要求具有  sysadmin  固定伺服器角色或  db_owner  固定資料庫角色的成員身份。

示例

A.   收縮資料庫並指定可用空間的百分比

以下示例將減小  UserDB  使用者資料庫中資料檔案和日誌檔案的大小，以便在資料庫中留出 10% 的可用空間。

SQL 複製

DBCC SHRINKDATABASE (UserDB, 10);   GO

B.   截斷資料庫

以下示例將  AdventureWorks  示例資料庫中的資料和日誌檔案收縮到最後指定的盤區。

SQL 複製

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);

DBCC SHRINKFILE (Transact-SQL)

• 
  

適用物件： SQL Server（從 2008 版開始） Azure SQL 資料庫 Azure SQL 資料倉儲 並行資料倉儲

收縮當前資料庫的指定資料或日誌檔案大小。   可以使用它將一個檔案中的資料移到同一檔案組中的其他檔案，這會清空檔案，從而允許刪除資料庫。   可以將檔案收縮到小於建立大小，同時將最小檔案大小重置為新值。

  Transact-SQL 語法約定

語法

SQL 複製

   DBCC SHRINKFILE    (       { file_name | file_id }        { [ , EMPTYFILE ]        | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]       }   )   [ WITH NO_INFOMSGS ]

引數

file_name
要收縮的檔案的邏輯名稱。

file_id
要收縮的檔案的標識 (ID) 號。   若要獲取檔案 ID，請使用  FILE_IDEX  系統函式，或查詢當前資料庫中的  sys.database_files  目錄檢視。

target_size
整數，檔案的新大小（以 MB 為單位）。   如果未指定，DBCC SHRINKFILE 縮小到檔案建立大小。

 備註

可以使用 DBCC SHRINKFILE target_size 縮小空檔案的預設大小。   例如，如果建立一個 5 MB 的檔案，然後在檔案仍然為空的時候將檔案收縮為 3 MB，預設檔案大小將設定為 3 MB。   這隻適用於永遠不會包含資料的空檔案。

FILESTREAM 檔案組容器不支援此選項。
如果 target_size 已指定，DBCC SHRINKFILE 會嘗試將檔案收縮到目標大小。   要釋放的檔案區域中的已用頁移到檔案保留區域中的可用空間。   例如，對於 10MB 資料檔案，target_size 為 8 的 DBCC SHRINKFILE 操作會將檔案最後 2MB 中的所有已用頁移到檔案前 8MB 中的任何未分配頁區域中。   DBCC SHRINKFILE 不會收縮已超過所需儲存資料大小的檔案。   例如，如果使用 10 MB 資料檔案中的 7 MB，則帶有 target_size 為 6 的 DBCC SHRINKFILE 語句只能將該檔案收縮到 7 MB，而不能收縮到 6 MB。

EMPTYFILE
將指定檔案中的所有資料遷移到同一檔案組中的其他檔案。   也就是說，EMPTYFILE 將指定檔案中的資料遷移到同一檔案組中的其他檔案。   EMPTYFILE 確保不會將任何新資料新增到檔案中（儘管此檔案不是隻讀檔案）。   可以使用  ALTER DATABASE  語句刪除檔案。   如果你使用  ALTER DATABASE  語句更改檔案大小，只讀標誌會重置，並能新增資料。

對於 FILESTREAM 檔案組容器，無法使用 ALTER DATABASE 刪除檔案，除非 FILESTREAM 垃圾回收器已執行，並刪除了 EMPTYFILE 已複製到另一個容器的所有不必要檔案組容器檔案。   有關詳細資訊，請參閱  sp_filestream_force_garbage_collection (Transact-SQL)

 備註

有關刪除 FILESTREAM 容器的資訊，請參閱  ALTER DATABASE 檔案和檔案組選項 (Transact-SQL)  中的相應章節

NOTRUNCATE
無論是否指定 target_percent，將資料檔案末尾中的已分配頁移到檔案開頭的未分配頁區域中。   作業系統不會回收檔案末尾的可用空間，檔案的物理大小也不會改變。   因此，如果指定 NOTRUNCATE，檔案看起來就像沒有收縮一樣。   NOTRUNCATE 只適用於資料檔案。   日誌檔案不受影響。   FILESTREAM 檔案組容器不支援此選項。

TRUNCATEONLY
將檔案末尾的所有可用空間釋放給作業系統，但不在檔案內部移動任何頁。   資料檔案只收縮到最後分配的區。 如果使用 TRUNCATEONLY 指定，則會忽略 target_size。
TRUNCATEONLY 選項不會移動日誌中的資訊，但會刪除日誌檔案末尾的失效 VLF。   FILESTREAM 檔案組容器不支援此選項。

WITH NO_INFOMSGS
取消顯示所有資訊性訊息。

結果集

下表描述了結果集列。

列名	描述
DbId	資料庫引擎 試圖收縮的檔案的資料庫標識號。
FileId	資料庫引擎 試圖收縮的檔案的檔案標識號。
CurrentSize	檔案當前佔用的 8 KB 頁數。
MinimumSize	檔案最低可以佔用的 8 KB 頁數。   此數字對應於檔案的大小下限或最初建立大小。
UsedPages	檔案當前使用的 8 KB 頁數。
EstimatedPages	資料庫引擎 估計檔案能夠收縮到的 8 KB 頁數。

Remarks

DBCC SHRINKFILE 適用於當前資料庫的檔案。   有關如何更改當前資料庫的詳細資訊，請參閱  USE (Transact-SQL) 。

可以隨時停止執行 DBCC SHRINKFILE 操作，並保留任何已完成的工作。   如果你使用 EMPTYFILE 引數並取消操作，檔案不會被標記，以防新增其他資料。

當 DBCC SHRINKFILE 操作失敗時，則會引發錯誤。

其他使用者可以在檔案收縮期間使用資料庫，資料庫不必處於單使用者模式。   無需在單使用者模式下執行  SQL Server 例項，即可收縮系統資料庫。

收縮日誌檔案

對於日誌檔案， 資料庫引擎  使用 target_size 計算整個日誌的目標大小。   因此，target_size 是執行收縮操作後的日誌可用空間。   隨後，整個日誌的目標大小轉換為每個日誌檔案的目標大小。   DBCC SHRINKFILE 嘗試立即將每個物理日誌檔案收縮到其目標大小。   但是，如果部分邏輯日誌位於超出目標大小的虛擬日誌中，則 資料庫引擎 將釋放盡可能多的空間，併發出一條資訊性訊息。   該訊息說明需要執行哪些操作來將邏輯日誌移出位於檔案末尾的虛擬日誌。   執行這些操作以後，DBCC SHRINKFILE 可用於釋放剩餘空間。

因為日誌檔案只能收縮到虛擬日誌檔案邊界，所以可能無法將日誌檔案收縮到小於虛擬日誌檔案（即使沒在使用它）。   資料庫引擎 在日誌檔案建立或擴充套件時，動態選擇虛擬日誌檔案大小。

最佳做法

在計劃收縮檔案時，請考慮以下資訊：

• 在執行會產生大量未用空間的操作（如截斷表或刪除表操作）後，執行收縮操作最有效。

• 大多數資料庫都需要一些可用空間，以供常規日常操作使用。   如果反覆收縮資料庫，並且它的大小再次增長，那麼常規操作可能需要收縮空間。   在這種情況下，反覆收縮資料庫是一種無謂的操作。

• 收縮操作不保留資料庫中索引的碎片狀態，通常還會在一定程度上增加碎片。   此類碎片是不要反覆收縮資料庫的另一個原因。

• 按順序而非同時縮小同一資料庫中的多個檔案。   對系統表的爭用可能會導致阻塞，進而導致延遲。

故障排除

本部分介紹如何診斷和更正在執行 DBCC SHRINKFILE 命令時可能發生的問題。

檔案不收縮

如果在執行無錯誤收縮操作後檔案大小未改變，請嘗試執行以下操作，驗證檔案是否有足夠的可用空間：

• 執行以下查詢。

SQL 複製

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB FROM sys.database_files;

• 執行  DBCC SQLPERF  命令以返回事務日誌中使用的空間。

如果可用空間不足，收縮操作無法進一步縮小檔案大小。

通常情況下，似乎不收縮的是日誌檔案。   導致這種不收縮的原因通常是，日誌檔案尚未截斷。   若要截斷日誌，可以將資料庫恢復模式設定為 SIMPLE，或者先備份日誌，再重新執行 DBCC SHRINKFILE 操作。

收縮操作受阻

在 基於行版本控制的隔離級別 下執行的事務可能會阻止收縮操作。   例如，如果在執行 DBCC SHRINK DATABASE 操作時，正在基於行版本控制的隔離級別下執行大型刪除操作，那麼收縮操作會等到刪除操作完成，然後才會繼續。   出現這種阻塞時，DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 操作會將資訊性訊息（對於 SHRINKDATABASE 為 5202，對於 SHRINKFILE 為 5203）列印輸出到 SQL Server 錯誤日誌。   在第一個小時內，此訊息每五分鐘記錄一次，之後每一小時記錄一次。   例如，如果錯誤日誌包含以下錯誤訊息，則會發生以下錯誤：

SQL 複製

DBCC SHRINKFILE for file ID 1 is waiting for the snapshot    transaction with timestamp 15 and other snapshot transactions linked to    timestamp 15 or with timestamps older than 109 to finish.

此訊息指明，時間戳早於 109（收縮操作完成的最後一個事務）的快照事務正在阻止收縮操作。   它還指明， sys.dm_tran_active_snapshot_database_transactions  動態管理檢視中的 transaction_sequence_num 或 first_snapshot_sequence_num 列包含值 15。   如果 transaction_sequence_num 或 first_snapshot_sequence_num 檢視列包含的數字小於收縮操作完成的最後一個事務 (109)，收縮操作會等待這些事務完成。

若要解決此問題，請執行下列任務之一：

• 終止阻止收縮操作的事務。
• 終止收縮操作。   如果收縮操作終止，所有已完成的工作都會保留。
• 不執行任何操作，並允許收縮操作等到阻塞事務完成。

許可權

要求具有  sysadmin  固定伺服器角色或  db_owner  固定資料庫角色的成員身份。

示例

將資料檔案收縮到指定的目標大小

以下示例將  UserDB  使用者資料庫中名為  DataFile1  的資料檔案的大小收縮到 7 MB。

SQL 複製

USE UserDB;   GO   DBCC SHRINKFILE (DataFile1, 7);   GO

將日誌檔案收縮到指定的目標大小

以下示例將  AdventureWorks  資料庫中的日誌檔案收縮到 1 MB。   若要允許 DBCC SHRINKFILE 命令收縮檔案，首先需要通過將資料庫恢復模式設定為 SIMPLE 來截斷該檔案。

SQL 複製

USE AdventureWorks2012;   GO   -- Truncate the log by changing the database recovery model to SIMPLE.   ALTER DATABASE AdventureWorks2012   SET RECOVERY SIMPLE;   GO   -- Shrink the truncated log file to 1 MB.   DBCC SHRINKFILE (AdventureWorks2012_Log, 1);   GO   -- Reset the database recovery model.   ALTER DATABASE AdventureWorks2012   SET RECOVERY FULL;   GO

C.   截斷資料檔案

下面的示例將截斷  AdventureWorks  資料庫中的主資料檔案。   需要查詢  sys.database_files  目錄檢視以獲得資料檔案的  file_id 。

SQL 複製

USE AdventureWorks2012;   GO   SELECT file_id, name   FROM sys.database_files;   GO   DBCC SHRINKFILE (1, TRUNCATEONLY);

D.   清空檔案

下面的示例展示瞭如何清空檔案，這樣檔案就能從資料庫中刪除。   為了方便此示例進行展示，先建立包含資料的資料檔案。

SQL 複製

USE AdventureWorks2012;   GO   -- Create a data file and assume it contains data.   ALTER DATABASE AdventureWorks2012    ADD FILE (       NAME = Test1data,       FILENAME = 'C:\t1data.ndf',       SIZE = 5MB       );   GO   -- Empty the data file.   DBCC SHRINKFILE (Test1data, EMPTYFILE);   GO   -- Remove the data file from the database.   ALTER DATABASE AdventureWorks2012   REMOVE FILE Test1data;   GO

另請參閱

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKDATABASE (Transact-SQL)
FILE_ID (Transact-SQL)
sys.database_files (Transact-SQL)
收縮檔案

---

---

About Me

........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub（ http://blog.itpub.net/26736162 ）、部落格園（ http://www.cnblogs.com/lhrbest ）和個人weixin公眾號（ xiaomaimiaolhr ）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ........................................................................................................................ ● QQ群號： 230161599 （滿） 、618766405 ● weixin群：可加我weixin，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ） ，註明新增緣由 ● 於 2019-04-01 06:00 ~ 2019-04-30 24:00 在魔都完成 ● 最新修改時間：2019-04-01 06:00 ~ 2019-04-30 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店 ： https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的資料庫類叢書 ： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班 ： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁 ： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 weixin客戶端 掃描下面的二維碼來關注小麥苗的weixin公眾號（ xiaomaimiaolhr ）及QQ群（DBA寶典）、新增小麥苗weixin， 學習最實用的資料庫技術。 ........................................................................................................................

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2642414/，如需轉載，請註明出處，否則將追究法律責任。