Friday, December 12, 2008

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.

Wednesday, December 10, 2008

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.

Transaktionsloggen går inte att minska!

Det är inte ovanligt att transaktionsloggen kan vara lite svår att hantera. Oftast går det dock att lösa. Men det kan hända att den är omöjlig att minska ner trots alla kända trix. Då finns det en nödlösning att ta till. Lösningan är att göra Detach på databasen och sedan döpa om loggfilen. Sen Attacha man den igen fast utan transaktion loggen. Då skapas det en ny från skratch. Voila! Loggen är nu bara någon mb stor.