整理丨諾亞
出品 | 51CTO技術(shù)棧（微信號：blog51cto）
在企業(yè)IT基礎(chǔ)設(shè)施的維護(hù)中，舊有系統(tǒng)的升級是一項長期挑戰(zhàn)。
想象一下，你的企業(yè)是一臺老爺車，雖然還能在路上跑，但發(fā)動機(jī)已經(jīng)在咯吱作響。但老板還是堅持：“只要它還能跑，就別急著換零件。”只有你在擔(dān)心，這臺老爺車隨時會因?yàn)槿鄙僮钚碌陌踩a(bǔ)丁而在路上熄火。
這一現(xiàn)象并不罕見。最近，IT資產(chǎn)管理系統(tǒng)平臺Lansweeper發(fā)起的一項調(diào)查又證明了這一點(diǎn)。這次，他們瞄準(zhǔn)了數(shù)據(jù)庫管理領(lǐng)域，重點(diǎn)聚焦微軟SQL Server。根據(jù)其最新數(shù)據(jù)，許多企業(yè)仍在使用已經(jīng)或即將超出微軟官方支持期限的SQL Server版本，這不僅增加了安全風(fēng)險，也影響了企業(yè)對新技術(shù)的采納和應(yīng)用。
你的企業(yè)使用SQL Server嗎，如果用的話，又用了多久呢？
根據(jù)Lansweeper平臺首席戰(zhàn)略官Roel Decneut的說法，該公司掃描了一百多萬個SQL Server實(shí)例，發(fā)現(xiàn)其中19.8%現(xiàn)在已經(jīng)不受微軟支持。
圖片
如圖可得，12%運(yùn)行的是SQL Server 2014。值得注意的是，該版本將于7月9日退出擴(kuò)展支持——這意味著下個月初不再受微軟支持的SQL Server比例將上升到32%。
當(dāng)然客戶可以選擇付費(fèi)，在接下來的三年內(nèi)繼續(xù)接收SQL Server 2014的安全更新。不過這也只是權(quán)宜之計。
眾所周知，微軟企圖讓用戶從Windows 10遷移到Windows 11時都有費(fèi)盡周折、力不從心之感，如今IT管理員們也面臨著類似處境，但他們的問題遠(yuǎn)沒有那么廣為人知。
誠然，IT專業(yè)人士都非常清楚在過時軟件上運(yùn)行關(guān)鍵業(yè)務(wù)流程的風(fēng)險，但如何說服決策層撥款進(jìn)行更新可能頗具挑戰(zhàn)。
Decneut在2019年加入Lansweeper之前是在微軟任職了18年的老員工，他曾參與SQL Server 2008和2012的發(fā)布團(tuán)隊。
“那時候讓人們放棄舊版本就是一個問題，”他說，“我認(rèn)為這與你運(yùn)行關(guān)系型數(shù)據(jù)庫的主要原因有關(guān)，那就是在其基礎(chǔ)上構(gòu)建應(yīng)用程序。而這些應(yīng)用程序的粘性正是造成這種情況的原因。”
Decneut提到，過去幾十年中對向后兼容性的不一致處理方式可能也影響了升級。Lansweeper的代理甚至檢測到了幾個運(yùn)行SQL Server 7的實(shí)例。在此背景下想要將運(yùn)行在該版本上的數(shù)據(jù)庫升級到最新、最強(qiáng)大的SQL Server，唯有祝你好運(yùn)。
目前SQL Server 2022是最新版本，但有44%的實(shí)例運(yùn)行的是2019年的版本。另外，SQL Server 2017占13.5%，2016版占比不到10%，再往前就是古董堆里的更過時的版本。在SQL Server 2014的12%之后，SQL Server 2012占9%。SQL Server 2008則徘徊在接近8%左右。
Decneut認(rèn)為，企業(yè)升級缺乏足夠的誘因，因?yàn)楹芏嗷A(chǔ)商業(yè)應(yīng)用設(shè)計得非常堅固，沒有多少花哨的功能。后續(xù)版本提供的新功能往往沒有任何吸引力，因?yàn)槠髽I(yè)不需要這些東西，他們只需要系統(tǒng)運(yùn)行即可。
微軟的商業(yè)模式要求用戶遷移到新版本，但事實(shí)上企業(yè)可能只有在面臨重大漏洞時才會關(guān)心更新問題。就像Decneut提到的：“只有當(dāng)房子著火了——存在重大漏洞時，才會有人去關(guān)心這個問題。”
“因?yàn)槲覀円呀?jīng)在向云遷移，我們在做這個，在做那個，現(xiàn)在又在考慮人工智能。我認(rèn)為我們在技術(shù)世界中養(yǎng)成了一個不好的習(xí)慣，就是對之前的事情不夠關(guān)心。而很多問題正是由此產(chǎn)生。”
不僅是微軟，其他數(shù)據(jù)庫供應(yīng)商也面臨客戶堅持使用過時代碼的問題。
Percona的技術(shù)布道者Dave Stokes在采訪中如是描述：“一方面，對于SQL Server實(shí)例超出支持范圍我并不感到驚訝——‘如果沒壞，就別修它’這條生活諺語在技術(shù)圈同樣適用。但我也意識到，這可能成為規(guī)避解決棘手問題的托辭。”
Stokes還指出，開發(fā)者和DBA可能不愿意被綁定在過時的數(shù)據(jù)庫軟件版本上，因?yàn)樗麄冨e過了新特性和功能。“做出這些改變可能很難，但這并不意味著就不應(yīng)該去做。開發(fā)者不想被綁定在一個已經(jīng)過期的數(shù)據(jù)庫軟件版本上。他們不僅錯過了后續(xù)版本中修復(fù)的錯誤，還錯過了能讓他們的工作更輕松的新特性和功能。”
Stokes補(bǔ)充說：“開源數(shù)據(jù)庫也同樣面臨生命周期結(jié)束的挑戰(zhàn)。MySQL 5.7版本去年十月就已經(jīng)達(dá)到了生命末期狀態(tài)，但該版本仍代表了Percona監(jiān)控和管理報告系統(tǒng)中的很大一部分。Percona提供的超期支持非常廣泛。”
隨著人工智能等新技術(shù)的興起，企業(yè)在追求創(chuàng)新的同時，也必須解決舊有系統(tǒng)的升級難題。企業(yè)需要不斷更新和維護(hù)其IT基礎(chǔ)設(shè)施的挑戰(zhàn)，以保持競爭力和安全性。
參考鏈接：https://www.theregister.com/2024/06/17/outdated_sql_server/
責(zé)任編輯：武曉燕來源： 51CTO技術(shù)棧
在創(chuàng)建數(shù)據(jù)庫之前，需要先確定數(shù)據(jù)庫的名稱、所有者、大小、存儲該數(shù)據(jù)庫的文件和文件組。
數(shù)據(jù)庫所有者：創(chuàng)建數(shù)據(jù)庫的用戶。一般情況下，大多數(shù)產(chǎn)品對象由數(shù)據(jù)庫所有者擁有。
語法格式如下：
CREATE DATABASE database_name
[ ON
[ PRIMARY ] [ ＜filespec＞ [ ,...n ]
[ , ＜filegroup＞ [ ,...n ] ]
[ LOG ON { ＜filespec＞ [ ,...n ] } ]
]
[ COLLATE collation_name ]
][;]
參數(shù)說明：
database_name：數(shù)據(jù)庫名稱。
ON：指定以顯式定義方式指定存儲數(shù)據(jù)庫數(shù)據(jù)部分的數(shù)據(jù)文件。
PRIMARY:指定＜filespec＞列表中的主文件。在＜filespec＞項中的第一個文件將成為主文件。如果沒有指定PRIMARY則默認(rèn)第一個文件將成為數(shù)據(jù)庫主文件。
LOG ON：指定存儲數(shù)據(jù)庫日志的日志文件。LOG ON后跟著以逗號分隔的用于定義日志文件的＜filespec＞項列表。不指定LOG ON，將自動創(chuàng)建一個日志文件，文件大小為該數(shù)據(jù)庫的所有數(shù)據(jù)文件大小總和的1/4或512 KB，取兩者之中的較大者。
COLLATE collation_name：指定數(shù)據(jù)庫的默認(rèn)排序規(guī)則。排序規(guī)則名稱包括Windows排序規(guī)則、SQL排序規(guī)則名稱。未指定排序規(guī)則，則將SQL Server實(shí)例的默認(rèn)排序規(guī)則分配為數(shù)據(jù)庫的排序規(guī)則。
＜filespec＞部分主要用于控制文件屬性，語法格式如下：
(
NAME=logical_file_name ,
FILENAME='os_file_name'
[ , SIZE=size [ KB | MB | GB | TB ] ]
[ , MAXSIZE={ max_size [ KB | MB | GB | TB ] | UNLIMITED } ]
[ , FILEGROWTH=growth_increment [ KB | MB | GB | TB | % ] ]
) [ ,...n ]
logical_file_name：指定文件的邏輯名稱。logical_file_name必須在數(shù)據(jù)庫中唯一，必須符合規(guī)定的標(biāo)識符規(guī)則。
' os_file_name '：指定操作系統(tǒng)（物理）文件名稱。執(zhí)行創(chuàng)建數(shù)據(jù)庫語句前，指定文件路徑必須存在。如果指定了UNC（通用命名約定）路徑，則無法設(shè)置SIZE、MAXSIZE和FILEGROWTH參數(shù)。
size：指定文件的初始大小。未指定主文件指定size，數(shù)據(jù)庫引擎將使用model數(shù)據(jù)庫中的主文件的大小。如果指定了輔助數(shù)據(jù)文件或日志文件，但未指定該文件的size，則數(shù)據(jù)庫引擎將以1 MB作為該文件的大小。
可以使用千字節(jié)（KB）、兆字節(jié)（MB）、千兆字節(jié)（GB）或兆兆字節(jié)（TB）后綴，默認(rèn)單位為MB。
max_size：指定文件可增大到的最大值，可以使用KB、MB、GB和TB后綴，默認(rèn)單位為MB。
UNLIMITED：指定文件可以增長到磁盤空間已滿。在SQL Server中，指定為不限制增長的日志文件的最大值為2 TB，而數(shù)據(jù)文件的最大值為16 TB。
growth_increment：指定每次需要新空間時為文件添加的空間量。growth_increment值不能超過MAXSIZE設(shè)置值。該值可以使用MB、KB、GB、TB或百分比（%）為單位指定。默認(rèn)值為MB。growth_increment值為0時表明自動增長被關(guān)閉，不允許增加空間。
如果未指定FILEGROWTH，則數(shù)據(jù)文件的默認(rèn)值為1 MB，日志文件的默認(rèn)增長比例為10%，并且最小值為64 KB。
＜filegroup＞部分主要用于控制文件組屬性，語法格式如下：
FILEGROUP filegroup_name [ DEFAULT ]
＜filespec＞ [ ,...n ]
filegroup_name：必須在數(shù)據(jù)庫中唯一，不能是系統(tǒng)提供的名稱PRIMARY和PRIMARY_LOG。
DEFAULT：指定文件組為數(shù)據(jù)庫中的默認(rèn)文件組。
create database TestDB
會根據(jù)SQLServer默認(rèn)設(shè)置（文件存儲位置、文件增加大小等）創(chuàng)建數(shù)據(jù)庫。
IF DB_ID (N'TestDB') is not null
-- 判斷數(shù)據(jù)庫是否存在如果存在則先刪除
DROP DATABASE TestDB
GO
CREATE DATABASE TestDB
ON
( NAME=TestDB,-- 邏輯數(shù)據(jù)庫文件名
FILENAME='D:\TestDB.mdf',
SIZE=10,
MAXSIZE=200,
FILEGROWTH=5 )
LOG ON
( NAME=TestDB_log,-- 邏輯數(shù)據(jù)庫日志文件名
FILENAME='D:\TestDB_log.ldf',
SIZE=5MB,
MAXSIZE=50MB,
FILEGROWTH=5MB ) ;
USE master
GO
IF DB_ID (N'TestDB') is not null -- 判斷數(shù)據(jù)庫是否存在如果存在則先刪除
DROP DATABASE TestDB
GO
CREATE DATABASE TestDB
ON
PRIMARY
(NAME=TestDB1,
FILENAME='d:\TestDB1.mdf',
SIZE=100MB,
MAXSIZE=200,
FILEGROWTH=20),
( NAME=TestDB2,
FILENAME='d:\TestDB2.ndf',
SIZE=100MB,
MAXSIZE=200,
FILEGROWTH=20)
LOG ON
(NAME=TestDB_log1,
FILENAME='d:\TestDB_log1.ldf',
SIZE=30MB,
MAXSIZE=100,
FILEGROWTH=10),
(NAME=TestDB_log2,
FILENAME='d:\TestDB_log2.ldf',
SIZE=100MB,
MAXSIZE=500,
FILEGROWTH=50) ;