MSSQL 2005 falsche logische Dateinamen

[mulle78 10]

Hi, nach eine DB Kopie werden die Namen im SQL Manager anderes angezeigt, als fon sys.database_files; wieder gegeben;

 

1 8D66B863-106D-4ABC-922A-EF0E1FABA10A 0 ROWS 1 QTODATA01 M:\QTODATA\QTODATA01.mdf

2 CE7B2C17-28BF-4CCF-A7E9-E7B877EA4A63 1 LOG 0 PTOLOG01 L:\QTOLOG\QTOLOG01.ldf

3 727E30E3-2BCA-40EF-9E89-7F15B85A57F0 0 ROWS 1 PTODATA02 M:\QTODATA\QTODATA02.ndf

4 E382A6CD-20AD-4642-BD7D-CB4ABEE7E790 0 ROWS 1 PTODATA03 M:\QTODATA\QTODATA03.ndf

5 F390820A-AC98-4FD7-801B-7779572E2786 0 ROWS 1 PTODATA04 M:\QTODATA\QTODATA04.ndf

6 6A4F4BD9-6366-449E-AE24-1399704011E0 0 ROWS 1 PTODATA05 M:\QTODATA\QTODATA05.ndf

7 AFAB9B63-61F3-4FA0-80E2-3A10668FD2FC 0 ROWS 1 PTODATA06 M:\QTODATA\QTODATA06.ndf

8 F19D8547-2543-49E8-9153-8CD729260155 0 ROWS 1 PTODATA07 M:\QTODATA\QTODATA07.ndf

9 5ED8BC71-5291-4853-BD8D-04CDBAB773AF 0 ROWS 1 PTODATA08 M:\QTODATA\QTODATA08.ndf

10 56E1D67A-3938-48DB-83C5-469D92836E6A 0 ROWS 1 PTODATA09 M:\QTODATA\QTODATA09.ndf

11 FB417EA2-5849-4CA7-8686-6F575454FA96 0 ROWS 1 PTODATA10 M:\QTODATA\QTODATA10.ndf

 

Was kann ich tun, um die Daten in dem collum name zu korrigieren. Dort steht überall QTODATA## im Enterprise Manager und ich kann die Dateien nicht mehr modifizieren, da der SQL Manager sie nicht finden kann.

[NilsK 2.934]

Moin,

 

was genau hast du gemacht?

 

Ich rate erheblich davon ab, in den Systemtabellen herumzufuhrwerken. Stelle notfalls die Datenbanken vom letzten Backup wieder her.

 

Gruß, Nils

[mulle78 10]

Ich habe eine homogene Datenbankkopie mit SAP Boardmitteln gemacht; Datafiles kopiert, attached, SQL Script ausgeführt... nur jetzt scheinbar eine Inkonsistenz bei den logischen Dateinamen in der DB.

 

habe jetzt versucht:

 

ALTER DATABASE QTO

MODIFY FILE (NAME = 'PTODATA02'

,NEWNAME = 'QTODATA02')

 

Msg 1828, Level 16, State 3, Line 1

The logical file name "QTODATA02" is already in use. Choose a different name.

 

; ich meine die Spalte "name" in sys.database_files. Dort steht z.B. 'PTODATA02'; Im Enterprise Manager jedoch in der Spalte Logical Name 'QTODATA02'. Und da scheint der `Gap?

 

ps: bei dem Versuch 'QTODATA02' um zu benennen, sagt er folgendes... könn ich jetzt z.B. einfach mal versuchen 'PTODATA02' nach 'XTODATA02' um zu benennen, weil 'QTODATA02' ja auf einer inkonsistenten Weise schon existiert und später noch mal 'XTODATA02' zurück nach 'QTODATA02' ?

 

Msg 5041, Level 16, State 1, Line 1

MODIFY FILE failed. File 'QTODATA02' does not exist.

 

'QTODATA02' will er nicht umbennenen, weil es nicht existiert

'PTODATA02' will er nicht nach 'QTODATA02' umbennenen, weil es angeblich existiert?

 

Das wiederspricht sich doch? Wo liegen die Daten denn noch, außer in sys.database_files; irgend ein inkonsistentes Shared Memory Objekt? Ich hatte DB und Manager eieentlich durch gestartet, nur nicht die ganze Maschine...

[mulle78 10]

ALTER DATABASE QTO

MODIFY FILE (NAME = 'PTODATA03'

,NEWNAME = 'XTODATA03')

 

ging, und kann jetzt 'XTODATA03' wieder mit dem Enterprise Manager bearbeiten.

 

ALTER DATABASE QTO

MODIFY FILE (NAME = 'XTODATA03'

,NEWNAME = 'QTODATA03')

 

geht auch... jetzt ist's wieder konsistent... danke :-)

[NilsK 2.934]

Moin,

 

danke für deine Selbstgespräche.

 

Gruß, Nils

[mulle78 10]

gelöst über ein anderes Forum, und die Lösung soll ja nicht vorenthalten werden...

[NilsK 2.934]

Moin,

 

schön und gut, aber es lässt sich absolut nicht erkennen, was zu deiner Situation geführt hat. Da finde ich Anleitungen zum Manipulieren der Systemtabellen schon ziemlich gefährlich. Um es deutlich zu sagen: Das ist alles andere als Best Practice!

 

Gruß, Nils

[mulle78 10]

Seh ich nicht so, nur weil man ein Problem nicht unbedingt erklären kann, sollte man doch den einfachsten Weg beschreiten, diesen zu lösen. Und einen von dir vorgeschlagen Restore, wäre hier nicht möglich, da nicht sicher seit wann die Inkonsistenz bestand. Somit wäre diese Lösung vermutlich keine Lösung und hätte nur Zeit gekostet, aber keinen Effekt.

 

Wer solche Änderungen an den Systemtabellen vornimmt sollte auf alle Fälle vorher sicher stellen, eine Vollsicherung zu haben.

 

Zur Not hätte ich die DB detached und neu attached...

 

ps: Ich habe im ersten Beitrag geschrieben, dass es duch eine Standard homogene Systemkopie entstanden sein wird, mit DB Umbenennung....

[NilsK 2.934]

Moin,

 

eine "Standard homogene Systemkopie" ist keine Bezeichnung, unter der sich jemand außer dir was vorstellen kann.

 

Es mag sein, dass der beschrittene Weg in deiner Situation erfolgreich war. Da diese Situation aber eben nicht einschätzbar ist, warne ich davor, diesen Weg für diffuse Probleme zu empfehlen. Er ist brandgefährlich. Immerhin haben wir hier viele Leute, die sich mit SQL Server nicht weiter auskennen.

 

EOT für mich.

 

Gruß, Nils