Kategorie-Archiv: SQL

SQL Server Datenbank-Kompatibilitäts-Level upgraden (Aktualisieren des Datenbank-Kompatibilitätsgrads)

Veröffentlicht am von — Keine Kommentare ↓

Wenn Microsoft eine neue Version des SQL Servers released, bleiben neue Funktionen in der Regel der neuesten „Kompatibilitätsstufe“ vorbehalten. Beispielsweise ist die „Parameter Sensitive Plan Optimization (PSPO)“ aus dem SQL Server 2022 nur in Datenbanken verfügbar, die unter der Kompatibilitätsstufe („Level“) SQL Server 2022 ausgeführt werden.

Datenbanken behalten ihr Kompatibilitätslevel auch bei einem Upgrade des Servers, jeder SQL kann Datenbanken jeder älteren Version ausführen. Grundsätzlich eine gute Idee. Das bedeutet aber, ein [DB]Admin muss je nach Software ab und zu die Datenbanken aktualisieren. Manchmal wegen der neuen Features, manchmal weil Software das benötigt.

SQL Server Kompatibilitätsgrad / Kompatibilitätslevel

Wichtig: Die Versionsnummern für SQL Server und Azure SQL-Datenbank sind nicht so richtig miteinander vergleichbar. Azure SQL basiert zwar auf dem gleichen Code, aber die SQL Engine in Azure ist „immer“ die neueste. Zum Beispiel ist v12 von Azure SQL „neuer“ als v15 von einem lokalen SQL Server.

80SQL Server 2000
90SQL Server 2005
100SQL Server 2008
110SQL Server 2012
120SQL Server 2014
130SQL Server 2016
140SQL Server 2017
150SQL Server 2019 (+Azure SQL)
160SQL Server 2022

Lösung

Es gibt zwei Möglichkeiten, das Upgrade für eine Datenbank auszuführen.

Microsoft SQL Management Studio

Im SMSS geht das in der grafischen Oberfläche sehr komfortabel:

  1. SMSS „Als Administrator“ starten
  2. Mit dem SQL Server verbinden
  3. Rechte MT auf die Datenbank > Eigenschaften
  4. Links in der Liste auf „Optionen“ > Rechts das „Kompatibilitäts Level“ auswählen

SQL Kommando

An einer SQL Shell, einer beliebigen – solange mit DBO-Rechten verbunden, kann man das mit diesem Einzeiler erledigen:

ALTER DATABASE <DB-NAME>
SET COMPATIBILITY_LEVEL = 150

WSUS 4 Performance optimieren durch Datenbank-Reindexierung, Löschen und manuelles bearbeiten

Veröffentlicht am von — 6 Kommentare ↓

Der WSUS unter Windows Server 2012/2012R2 und 2016 zeigt ab und zu gewisse Performance-Schwächen. Das äußert sich beispielsweise in dem berüchtigten „Serverknoten zurücksetzen“ Fehler oder dem „Fehler bei der Verbindung zur WSUS-Datenbank“ Anzeige.

Lösung

Der WSUS-Server ist tatsächlich ein Performance-Fresser. die Update-Datenbank ist riesig. Nicht immer ist hier die WID (Windows-Interne Datenbank) die richtie Lösung. Wartungsscripts und Neuindexierungsjob gibt es hier leider nicht.

Tipp 1 – WSUS-Datenbank defragmentieren und neuindexieren

  1. WSUSDBMaintenance Scripts herunterladen (nicht auf die Version achten – läuft auch unter WSUS 4)
  2. Microsoft® Command Line Utilities 11 for SQL Server herunterladen und installieren (oder alternativ das SMSS verwenden)
  3. Die Scripts ausführen: 
    sqlcmd -E -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i WsusDBMaintenance.sql

Tipp 2 – Cleanup-Agent laufen lassen

Der WSUS „Assistent für die Serverbereinigung“ kann die Datenbank deutlich entschlacken (und für mehr Platz sorgen). Läuft der Assistent nicht durch, hilft oft dieser Artikel.

Tipp 3 – Mehr Leistung

Ein WSUS mit vier Kernen und 8Gb RAM kann etwa 5000 Clients gut und schnell bedienen. viele WSUS-Maschinen haben aber deutlich weniger Ressourcen; eine leichte Aufstockung kann hier wunder bewirken.

Tipp 4 – Abgelaufene oder ersetzte Updates löschen

Der Fehler in diesem Artikel kann auch die Ursache für Verbindungstimeouts des Konsolenclients sein.

Dieses SQL-Script löscht die Updates direkt in der Datenbank, ohne einen externen Binärassistenten. Alle diese Updates auf einmal, ohne manuelles suchen.

DECLARE @var1 INT 
DECLARE @msg nvarchar(100) 
CREATE TABLE #results (Col1 INT) INSERT INTO #results(Col1) 
EXEC spGetObsoleteUpdatesToCleanup 
DECLARE WC Cursor FOR SELECT Col1 FROM #results 
OPEN WC 
FETCH NEXT FROM WC INTO @var1 WHILE (@@FETCH_STATUS > -1) 
BEGIN SET @msg = 'Deleting ' + CONVERT(varchar(10), @var1) RAISERROR(@msg,0,1) WITH NOWAIT 
EXEC spDeleteUpdate @localUpdateID=@var1 
FETCH NEXT FROM WC INTO @var1 
END 
CLOSE WC 
DEALLOCATE WC 
DROP TABLE #results

Tipp 5 – SQL-Server Timeout für die WID/SUSDB hochsetzen/abschalten

Die meisten Konsolenaktionen laufen fehlerfrei durch, wenn man das SQL-Timout für querys entweder sehr hoch ansetzt, oder gleich ganz abschaltet. Achtung: Wenn man das Timeout abschaltet, laufen auch „tote“ Anfragen durch, bis sie fertig sind. Default sind 600 Sekunden.

USE SUSDB;  
GO  
EXEC sp_configure 'remote query timeout', 0 ;  
GO  
RECONFIGURE ;  
GO

Tipp 6 – IIS Prozess-Pool Timeout für die WSUS-Prozesse erhöhen

Ein sehr nerviger Fehler taucht im WSUS ab Windowss Server 2016 auf: „WSUS Verbindungsfehler – Serverknoten zurücksetzen„

IIS (Internetinformationsdienste) Konsole öffnen > Anwendungspools > WsusPool > „Erweiterten Einstellungen“ des Anwendungspools öffnen -> „Limit für den privaten Speicher“ auf „0“ setzen und Server neustarten. Der Reboot ist notwendig, ein Nuestart der IIS alleine reicht nicht.

Microsoft SQL Server (MSSQL) Msg 15150 Cannot Alter The User ‘dbo’

Veröffentlicht am von — Keine Kommentare ↓

Wenn man einen SQL Benutzer nicht vom SQL-Server entfernen kann, weil dieser Fehler auftritt („Error: 15150“), hat der Benutzer vermutlich noch ein Datenbankschema im Besitz.

Lösung

Der Besitz der Datenbank (des Schemas) muss einfach wieder „mit Gewalt“ übergeben werden. Wir machen das in aller Regel für den SA und vergeben dann als dieser neue Berechtigungen.

Use <DATENBANK>
GO
sp_changedbowner 'sa'
GO

Microsoft SQL Server 15128 „Die Optionen CHECK_POLICY und CHECK_EXPIRATION können nicht auf OFF festgelegt werden, wenn MUST_CHANGE auf ON festgelegt ist“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Nach der Anlage eines neuen SQL-Benutzers möchte der Admin den Haken bei „Benutzer muss das Kennwort bei der nächsten Anmeldung ändern“ entfernen. Das SQL Management Sudio beschwert sich darauf hin aber, das „MUST_CHANGE auf ON“ festgelegt sei:

Die Optionen CHECK_POLICY und CHECK_EXPIRATION können nicht auf OFF festgelegt werden, wenn MUST_CHANGE auf ON festgelegt ist. (Microsoft SQL Server, Fehler: 15128)

Lösung

Das Kennwort muss geändert werden, erst dann kann man die Optionen wieder anpassen. Die „Änderung“ kann aber auch das selbe Kennwort wie vorher sein.

Kurzfassung in T-SQL:

USE master;
ALTER LOGIN <sqluser> WITH PASSWORD = '<kennwort>';
ALTER LOGIN <sqluser> WITH CHECK_EXPIRATION = OFF; // Kennwortablauf
ALTER LOGIN <sqluser> WITH CHECK_POLICY = OFF; // Kennwortrichtlinie

Microsoft SQL-Server (MSSQL) Version und Edition anzeigen

Veröffentlicht am von — Keine Kommentare ↓

Und schon wieder so ein Fall von Selbst-Notiz. JEDESMAL muss ich googeln wie man die Version oder Edition des grade genutzten MS SQL-Servers anzeigt 🙄

Version anzeigen

SELECT @@version

Edition und Version anzeigen

SELECT
  CASE 
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '8%' THEN 'SQL2000'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '9%' THEN 'SQL2005'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '10.0%' THEN 'SQL2008'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '10.5%' THEN 'SQL2008 R2'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '11%' THEN 'SQL2012'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '12%' THEN 'SQL2014'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '13%' THEN 'SQL2016'     
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '14%' THEN 'SQL2017' 
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '15%' THEN 'SQL2019' 
     ELSE 'unknown'
  END AS Produktversion,
  SERVERPROPERTY('ProductLevel') AS Patchlevel,
  SERVERPROPERTY('Edition') AS Edition,
  SERVERPROPERTY('ProductVersion') AS Build