[SQL]使用 SSMS 在 SQL Server 2005 上升級 SQL 7 的小問題

正常來說 SQL Server 可以很容易的去掛載前三個版本內的資料庫檔案,但太鐵齒的狀況下還是會踩到雷

在之前的文章中 「升級資料庫主機的帳號對應」,主要是在幫朋友測試升級資料庫的時候所遇到的問題,本來想說既然測試完了,應該就可以正式來移機了,但很不湊巧的,看到正式要移轉的環境時,差點要去膜拜了。居然在 2019 年還可以看到 Windows NT 4.0 + SQL 7.0 的環境,這實在是太神奇了。 ( 雖然前年還有看到 SQL 6.5,但只能說那真是遇到骨董了 )

本來想說應該也只是個簡單任務,因此就直接請朋友開啟 SSMS,先把原本 SQL 7.0 的伺服器給關閉,然後把資料檔案複製到新的移轉主機上,把他升級到 SQL 2005 之後,再往後升級到 2017 的上面。但沒有想到在第一關機然就出現問題了,看朋友的操作也沒有多大的問題,就是開啟 SSMS ,選擇附加資料庫之後,按下「加入」的按鈕
然後選擇我們要掛載的檔案,這裡我使用原本在 SQL 7.0 上面的 pubs 資料庫來測試

但沒有想到就居然出錯了,而從訊息中也實在很難猜出來到底哪裡出錯了,忽然有點撞牆卡關了.....


而當自己決定不理他先去睡覺之後,起來後忽然想到,難道 SSMS 在掛載資料庫之前,莫非是下了甚麼樣的指令,才造成這樣的錯誤訊息嗎 ? 因此利用 SQL Profile 攔截一下 SSMS 所下的指令,把指令複製出來測試一下,果然 Bingo 看到錯誤的問題,原來是 SSMS 利用 dbcc checkprimaryfile 指令所造成的異常,那看起來問題就好解決了。

首先我們要先知道 dbcc checkprimaryfile 這個指令是做甚麼用途的,基本上 SSMS 要透過那個指令,來取得所要還原的資料檔案,他原本的資料庫名稱、版本和定序是甚麼,然後來組合後續的副載指令。而 dbcc checkprimaryfile 又只支援 SQL Server 2000 含以後的版本,因此就還是自己乖乖地用 sp_attach_db 的指令來掛載資料庫吧。

而當我們直接改用指令來掛載的時候,就可以看到資料庫很順利地掛載上來,並且完成必要的升級了

因此又順利的完成一個簡單任務,可以放心地去休假了。