Kvalitetsgranskning av databasmodell, SQL kod, databassäkerhet, backup/restore rutiner, utvecklingsrutiner och driftrutiner. Denna granskning syftar till…
Att namnge sin databas på ett vettigt sätt är självklart för de flesta. Det underlättar. Dock så kan man ibland behöva ändra namnet av olika anledningar, inget konstigt med det.
Att ändra namn på databasen är inte svårt, bara att använda sig av sp_renamedb.
Ex: EXEC master..sp_renamedb ‘GammaltNamn’,’NyttNamn’
Databasen har nu fått ett nytt namn och allt är frid och fröjd…eller? Nej, vi har bara ändrat namnet på själva databasen inte dess fysiska filnamn. Varför är detta viktigt, är det viktigt…?
Jag tycker nog att man inte bör slarva med detta. För en tid sedan var jag hos en kund och flyttade en massa databaser från en server till en annan. Det visade sig rätt snabbt att man döpt om de flesta av databaserna men inte tagit hand om de fysiska filnamnen. Nu var det så att det redan fanns databaser på min målserver med samma fysiska filnamn som de databaser jag höll på att flytta vilket resulterade i att min restore inte gick igenom pga att filnamnen var upptagna.
Om man hade tagit hand om filnamnen samtidigt som man döpte om databaserna hade detta inte varit ett problem. Detta gäller även om man tex gör restore på en databas med ett nytt namn.
Att ändra de fysiska filnamnen är inte heller svårt.
Ex:
ALTER DATABASE [DatabasNamn] MODIFY FILE (NAME=N’GammaltNamn’, FILENAME=N’NyttNamn’)
GO
ALTER DATABASE [DatabasNamn] MODIFY FILE (NAME=N’GammaltNamn_log’, FILENAME=N’NyttNamn_log’)
GO
Efter detta måste man ta databasen offline, döpa om filerna, och sedan ta databasen online igen.
Edit:
Här blev det en liten tankevurpa av mig. Precis som Thomas skriver i sin kommentar så kan man visst ha samma logiska filnamn på databaserna, jag menade såklart de Fysiska filnamnen, inget annat! Rätt skall vara rätt. Inlägget är nu ändrat för att spegla detta.