Faila över diskar i Windows kluster fungerar inte

Vid en failover kommer inte diskarna igång på den andra noden. Lösningen kan vara att disksignaturerna har försvunnigt från registret på den felande noden. Titta i clusterloggen om liknande felet nedan finns:
ERR Physical Disk : Online: Unable to open ClusDisk signature key 5d1005cb. Error: 2

Om så är fallet så titta i registret under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters\Signatures
Finns inte signaturen där så lägg till den. Lägg sedan till ett stringvärde som heter DiskName och låt det peka ut den disken som det gäller. Tex. \Device\Harddisk3 Titta I diskmanager för att se vilken enhet som mappat till vilken disk.

Fulltext Indexing Pausar

Fulltextindexeringen pausar vilket man inte vill. Detta orsakar en fördröjning när klienten skall söka med den. En lösning på detta problem kan vara att den försöker gå ut på Internet för att verifiera, detta kan man sätta av med kommandot sp_fulltext_service 'verify_signature', 0; Läs mer här:
http://support.microsoft.com/kb/915850

The Distributed Transaction Coordinator service terminated with service-specific error 3221229584

During a cluster maintenance where I removed one of the cluster nodes from the cluster and installed the SQL server as a standard standalone server I went in to problem to start the MSDTC. I got the specified error described above. It was quite simple to find out the solution. When paging thru the Registry I finded a path to the MSDTC log pointing to the old Qorum disk in the cluster. Just change this path and it works fine afterwards.

The SQL Server failed to initialize VIA support library [QLVipl.dll].

Råkade ut för ett delikat fel på ett kluster. Utan att jag vet varför så kunde inte SQL starta efter en failover. Följande kunde man hitta i loggen:

Error: 26055, Severity: 16, State: 1.
The SQL Server failed to initialize VIA support library [QLVipl.dll]. This normally indicates the VIA support library does not exist or is corrupted. Please repair or disable the VIA network protocol. Error: 0x7e.
Error: 17182, Severity: 16, State: 1.
TDSSNIClient initialization failed with error 0x7e, status code 0x60.
Error: 17182, Severity: 16, State: 1.
TDSSNIClient initialization failed with error 0x7e, status code 0x1.
Error: 17826, Severity: 18, State: 3.
Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
Error: 17120, Severity: 16, State: 1.
SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

Mycket märkligt då VIA protokollet är disablat default vid installation. Men mycket riktigt så stod det enablat i Configuration Managern. Enkelt, bara att ändra då eller? Jag gjorde det men fick samma fel. Vad är det nu tänkte jag efter tredje försöket och omstart av hela klustret. Efter tips från Microsoft så har jag nu lärt mig att protokollen går bara ändra om man kör följande kommando först.

cluster res "SQL Server" /removecheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLSERVER"

Ändra i Confguration Managern…

cluster res "SQL Server" /addcheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLSERVER"

Trots sin ganska goda erfarenhet av kluster så va detta en nyhet för mig. Kul att lära sig nått nytt. Frågan är bara hur hade protokollet ändrats?? Jag vet ju att det har varit korrekt innan då jag installerat det.

Har du loosat pw till SA usern i SQL 2000?

Det finns några lösningar att ta till. Bla att sniffa passwordet via nått monitoreringsverkty men det skall vi inte gå in på här. Utan vi titta i själva master databasen. Vi behöver en SQL server där vi känner till SA passwordet. Hämta password strängen för SA. Passwordet lagras i en systemtabell som heter SYSXLOGINS och finns i kolumnen password.

Select * from sysxlogins

0x0100EB14356A1C88E4092CB60ED894C9FEC8447E0640563874FF4326113F9E6E48F10B5F38572ACB8E785B83A91C

Spara undan denna sträng till senare. Nu stänger vi ner SQL tjänsten på servern vi inte känner till passwordet på. Kopiera sedan masterdatabasens filer till SQL servern där du känner till SA passwordet. Kopla den till systemet med ett annat namn än master. Kör sedan Queryanalyzer mot databasen och updatera den med password strängen som vi hämtade ut tidigare. Observera att man måste dels tillåta uppdateringar av systemtabeller och dels konvertera strängen till varbinary.

SP_CONFIGURE 'ALLOW UPDATES', 1
GO
RECONFIGURE WITH OVERRIDE
GO

Update sysxlogins set password = CONVERT (varbinary(256),0x0100EB14356A1C88E4092CB60ED894C9FEC8447E0640563874FF4326113F9E6E48F10B5F38572ACB8E785B83A91C)
where name = 'sa'


SP_CONFIGURE 'ALLOW UPDATES', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Sedan är det bara att flytta tillbaks databasfilerna till orginal servern och Voila! SA har nu samma lösen som servern du kände till passwordet för.