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.

Tuesday, June 17, 2008

Invalid OLEVERB structure. Error source: Microsoft Data Transformation Services (DTS) Package

När man flytta DTS paket till en ny SQL 2005 server så har jag sett detta felet några gånger. Felet beror på att kontot som kör SQLAgenten inte har rättigheter att skapa skript i foldern C:\Program Files\Microsoft SQL Server\80\Tools. Genom att slå på loggningen på paketet så syns detta tydligt. Microsoft SQL-DMO (80004005): [SQL-DMO]CreateFile error on 'Servernamn.Databas.LOG'.
Meningen är förmodligen att man inte skall köra DTS i 2005 så därför blir inte denna rättighet korrekt vid installationen.

Monday, June 9, 2008

Exception from HRESULT: 0xC0010014 (Microsoft.SqlServer.DTSRuntimeWrap

Varför går det inte att editera Maintenance jobb? När man väljer edit så får man felet Exception from HRESULT: 0xC0010014 (Microsoft.SqlServer.DTSRuntimeWrap Grottade ett tag och efter att har registrerat om dts.dll till 32 bitars versionen så fungerar det. Nått blir mismatch när man kör på en 64 bitars SQL. regsvr32 "c:\ProgramFiles(x86)\Microsoft SQL Server\90\dts\binn\dts.dll"

Why can I not edit the Maintenance jobs? When I chose edit I recive error Exception from HRESULT: 0xC0010014 (Microsoft.SqlServer.DTSRuntimeWrap. After some research it looks like it has something to do with the 64 bit SQL. I registred the dts.dll from the 32 bit folder and after that it works well. regsvr32 "c:\ProgramFiles(x86)\Microsoft SQL Server\90\dts\binn\dts.dll"

Saturday, March 15, 2008

Error 29109:

Error 29109: Team Foundation Report Server Configuration: Report Server Configuration encountered an unknown problem

Höll på med uppgradering utav Team Foundation Service idag och då dök detta problem upp. Lösningen var simpel när man väl viste vad det var. Det var helt enkelt frågan om en timeout när installations programmet skulle komma åt SQL Reporting Services. Genom att starta http://localhost/reports vilket tog flera minuter, så kompilerade man sidan igen och Installationsprogrammet kunde sedan gå vidare. Vad enkla felen kan vara ibland.

Man kom inte långt förrän nästa fel uppstod :-)

C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools\TfsDb.exe"
upgrade /server:"servername" /property:"TFS_SERVICE_ACCOUNT=NT AUTHORITY\NETWORK SERVICE;TFS_REPORTING_ACCOUNT=,DOMAIN\TFS;LCID=1033;VSTF_AS_INSTANCE=DATABASESERVERNAME;VSTF_AS_DATABASE=TFSWarehouse;VSTF_AS_ACCOUNT=" /showui:263404' returned non-zero value: 100.

Vad berode detta fel på då? Jo det var så enkelt att det fans XML filer för Analysis Server som dels inte innhöll något data, dels var det några som var korrupta. Detta syns inte via det grafiska verktyget under uppgraderingen utan man fick köra samma kommando som flemedelandet ovan i kommandotolken så kunde man enkelt se vad det stannade på. Jag undrar varför man inte loggar detta så man lättare kunde ta reda på vad det var som var fel?