Benutzer mit den meisten Antworten
SQL Server Umzug von 2012 zu 2017 - Daily Import dauert extrem lange

Frage
-
Hallo und Guten Morgen,
Alte Umgebung:
SQL Server 2012 (BI Lizenz)auf Windows Server 2008, Virtuelle Umgebung mit 32 GB RAM von VmWare
Neu Umgebung:
SQL Server 2017 (Entwickler Lizenz) auf Windows Server 2017, gleiche virtuelle Umgebung
Es wurde ein neuer Server aufgesetzt und SQL Server 2017 neu installiert. Danch haben wir die Daten von 2012 gesichert und auf den 2017er übertragen. Der Server läuft und ich komme auch an meine Reports / Cube wie gewohnt dran. Die Importzeit hat sich leider verdreifacht und ist so nicht tragbar.
Sowohl der Import der Daten für das Datawarehouse als auch die Dimensionserstellung dauert Faktor 2-3 länger.Wir haben schon den optimizer für fehlende Indizes aufgerufen und auch angelegt, aber leider keine Verbesserung.
Wer hat ähnliche Erfahrungen gemacht? Ich habe irgendwie den Eindruck, dass der SQL 2017 komplett langsamer ist. Wir haben den auch auf nicht virtueller Umgebung installiert und auch hier haben wir die extreme Zeiten.
Fehlt es eventuell an Speicher? Welche Einstellungen gibt es dies hier zu optimieren?
Danke für die Informationen.
Gruß Klaus
Antworten
-
Hallo Klaus,
mit SQL Server 2014 wurde ein neuer Cardinality Estimator eingeführt, der je nach Abfrage andere Ausführungspläne generiert, als mit der alten Version und das kann mit unter zu einer langsameren Ausführung führen.
Zum Test kannst Du mal den Datenbank Comp Level auf 2012 ändern oder den neuen CE abschalten.
Siehe
Cardinality Estimation (SQL Server)
SQL Server 2014’s new cardinality estimator (Part 1)Aber das hat nur Einfluss auf Abfragen, nicht auf einfache Importe. Da würde ich erst mal systemseitig Suchen, wie Netzwerk, VM Disk Einstellungen etc.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Freitag, 19. Juli 2019 06:05
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 30. Juli 2019 13:38
-
Hallo Klaus,
versuche einmal:
-- compatibility_level auf 140 setzen:
alter database CURRENT set compatibility_level = 140; -- Hast Du schon
und:
-- legacy_cardinality_estimation auf on setzen:
alter database scoped configuration set legacy_cardinality_estimation = on;
Gruß
Willi
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Freitag, 19. Juli 2019 06:03
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 30. Juli 2019 13:38
-
Hallo Willi,
140 und legacy *OFF hat die besten Werte gebracht. Mit Legacy *ON war es fast so langsam wie zuvor.
Wir haben nun den RAM auf 64 GB erhöht und nun scheint es relational zu passen. Der relationale Teil war deutlich schneller als unter 2012. Die Cube Erzeugung läuft gerade. Mal sehen.
Danke.
Gruß Klaus
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Freitag, 19. Juli 2019 06:03
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 30. Juli 2019 13:38
Alle Antworten
-
Hallo Klaus,
mit SQL Server 2014 wurde ein neuer Cardinality Estimator eingeführt, der je nach Abfrage andere Ausführungspläne generiert, als mit der alten Version und das kann mit unter zu einer langsameren Ausführung führen.
Zum Test kannst Du mal den Datenbank Comp Level auf 2012 ändern oder den neuen CE abschalten.
Siehe
Cardinality Estimation (SQL Server)
SQL Server 2014’s new cardinality estimator (Part 1)Aber das hat nur Einfluss auf Abfragen, nicht auf einfache Importe. Da würde ich erst mal systemseitig Suchen, wie Netzwerk, VM Disk Einstellungen etc.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Freitag, 19. Juli 2019 06:05
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 30. Juli 2019 13:38
-
Hallo Olaf,
danke für die schnelle Antwort.
In der Datebank stand noch Version 2012. Wir haben es auf 2017 geändert und siehe da, das eine SQL hat sich von 240 Sekunden auf 30 Sekunden beschleuinigt, aber auf dem alten 2012 SQL Server benötigt es nur 7 Sekunden.
Irgend etwas passt (noch) nicht.
Gruß Klaus
-
Hallo Klaus,
versuche einmal:
-- compatibility_level auf 140 setzen:
alter database CURRENT set compatibility_level = 140; -- Hast Du schon
und:
-- legacy_cardinality_estimation auf on setzen:
alter database scoped configuration set legacy_cardinality_estimation = on;
Gruß
Willi
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Freitag, 19. Juli 2019 06:03
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 30. Juli 2019 13:38
-
Hallo Willi,
140 und legacy *OFF hat die besten Werte gebracht. Mit Legacy *ON war es fast so langsam wie zuvor.
Wir haben nun den RAM auf 64 GB erhöht und nun scheint es relational zu passen. Der relationale Teil war deutlich schneller als unter 2012. Die Cube Erzeugung läuft gerade. Mal sehen.
Danke.
Gruß Klaus
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Freitag, 19. Juli 2019 06:03
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 30. Juli 2019 13:38
-
Ein Insert ist aber keine Abfrage!
Was ist denn dann das folgende Szenario :)
INSERT INTO dbo.TableName(FieldList) SELECT FieldList FROM dbo.Table1 INNER JOIN dbo.Table2 ... WHERE Prädikat
Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)