MS SQL Server 2012 Datenbank Optimieren, aber wie Richtig?

[Sunny61 806]

Japp anfangen werde ich damit auch ...

aber bis ich aus dem  Prog alle SELECT * Abfragen raus habe, haben wir die nächste Eiszeit :-)

Ich weis es wirklich nicht genau, aber ich denke mal wir reden hier ganz locker von Mehreren Tausend SQL Statments im Code :-)

OMG, Du solltest da wirklich besser auf Stored Procedures umstellen. Sowas hat in einem FE nix verloren.

[NorbertFe 2.034]

1. noch einmal bestätigen lassen, das es sich um vollwerttige SAS platten handelt ... --> Aussage JA !

2. habe ich mir natürlich noch das genaue Modell sagen lassen, damit ich das überprüfen kann ---> Soweit ich das Beurteilen kann sind es Vollwertige SAS platten

 

Model: Seagate Constellation ES.3 (ST2000NM0023) So um das Abschließend zu klären sind das nun SAS platten oder nicht ?[/size]

http://www.seagate.com/internal-hard-drives/enterprise-hard-drives/hdd/enterprise-capacity-3-5-hdd/?sku=ST2000NM0023

 

•World’s fastest 6TB nearline hard drives

http://www.seagate.com/www-content/product-content/constellation-fam/constellation-es/constellation-es-3/en-us/docs/constellation-es-3-data-sheet-ds1769-1-1210us.pdf

 

Schrub ich was von NL-SAS? ;)

 

Als ich den Server gekauft habe war eine Anforderung Schnelle Platten.....

Naja dann sollte man aber keine mit 7200RPM kaufen. ;)

 

 

Bye

Norbert

[Husker 0]

Moin,

 

schau dire mal den Datenbankoptimierungsratgeber im SQL Server Management Studio an.

 

Dass der Entwickler einer Datenbank gute Hinweise zur Optimierung geben kann, ist zwar richtig. Das Anlegen und Warten von Indizes gehört aber zu den Kernaufgaben eines Datenbankadministrators (DBA), weil diese Rolle mit der tatsächlichen Infrastruktur mehr zu tun hat.

 

Gruß, Nils

 

Hallo Nils,

ich möchte mich bei dir bedanken den dein Hinweis war eigentlich genau das was ich gesucht hatte ....

 

Vielleicht hier mal für leute die das gleiche Problem haben:

Mann kann über den Profiler im MSMMS z.b. 24 Stunden den Traffic der DB Aufzeichnen und von dem Tool analysieren lassen,

dieses Ermittelt das welche Indizies angebracht sind und mann kann diese gleich als T-SQL Script bekommen ....

 

Sicher wird das nicht das Ultimo sein aber in meinem Fall sagte das Tool Geschätzte Optimierung 97% :-)

[NorbertFe 2.034]

Und jetzt ist es schnell? :)

[Husker 0]

 

 

Und jetzt ist es schnell?

 

Schnell ist ein sehr Relativer Begriff ....

ich habe die Scripte noch nicht ausgeführt ,....

ich wollte vorher mal ein paar vergleichsmessungen machen um den Zeitunterschied gut bewerten zu können.

Dazu hatte ich aber noch keine zeit ... 

 

hört sich so an als ob du deine zweifel hast ...

[zahni 554]

Dafür  ist eine Testumgebung immer  gut. Wenn  man sie hat...

[Husker 0]

 

 

OMG, Du solltest da wirklich besser auf Stored Procedures umstellen

 

haben wir bereits im einsatz :-)

 

 

Dafür  ist eine Testumgebung immer  gut. Wenn  man sie hat...

Auch darum haben wir uns schon gekümmert,

leider hat die Testumgebung natürlich weniger Ressourcen als das PRD system ...

mehr war nicht verfügbar :-)

bearbeitet 19. November 2014 von Husker

[Sunny61 806]

haben wir bereits im einsatz :-)

 

Dann wird es Zeit die SELECT * Abfragen aus dem FE in SPs auszulagern.

[NorbertFe 2.034]

hört sich so an als ob du deine zweifel hast ...

Hört sich so an, als würdest du glauben 97% mal eben rauszuholen. Kann durchaus sein, aber ich glaubs erst, wenn ich es sehe. ;)

[Husker 0]

 

 

Hört sich so an, als würdest du glauben 97% mal eben rauszuholen. Kann durchaus sein, aber ich glaubs erst, wenn ich es sehe.  ;) 

 

Quatsch ..

Das war nur das was die Analyse ergeben hat ....

wenn die Performance um 10% zunehmen würde wäre ich schon zufrieden :-)

ICh weis ja nicht mal auf was sich dieser Wert bezieht :-)

 

Solbald ich Handfeste Resultate habe werde ich das hier auch mitteilen ...

kann schon sein das das kaum etwas bringen wird, weiß ich aber erst wenn ich es getestet habe

Dann wird es Zeit die SELECT * Abfragen aus dem FE in SPs auszulagern.

 

naja neeee

also wenn ich das alles richtig geschnallt habe sind SELECT * immer Doof da dies zwangsläufig intern zu einem Loop führen 

und da ist es egal ob es vom FE oder SP kommt .... KLAR die SP werden immer schneller sein da sie lokal laufen ...

aber das wäre doch ein wenig so als würdest du an dein Auto ne Rakete bauen ohne zuerst mal einen blick in den Motor zu werfen ...

ja der vergleich hinkt etwas aber ein anderer fällt mir gerade nicht ein !

[zahni 554]

Warum soll ein Select * "ein Loop"  erzeugen bzw. was meinst  Du damit?

Eine Select *  liefert zunächst alle Spalten eine Abfrage, egal ob der Client alle Spalten braucht. Ob alle Zeilen abgerufen werden, hängt von der Where-Clausel ab und wie der Client auf das ResultSet zugreift (Stichwort z.B. Scrollable ResultSet).

Eine Abfrage ist  auch performanter, wenn nur  die Spalten abgefragt werden, die man wirklich benötigt.

@Sunny, wie sollen hier  SP's helfen?

[Sunny61 806]

@Sunny, wie sollen hier  SP's helfen?

Eine SP wird erstellt, der SQL-Server erstellt einen Ausführungsplan und optimiert die Ausführung der SP. Wenn ich allerdings jedesmal eine SELECT Abfrage an das Backend schicke, muß das jedesmal gemacht werden. Eine SP auf einem SQL Server ist jeder SELECT Abfrage aus einem FE vorzuziehen.

 

Natürlich ist das kein Allheilmittel, und wenn die SP auch mit SELECT * erstellt wird, kann es nicht viel besser werden, aber besser als ein SELECT * vom FE abgeschickt ist es IMHO allemal.

[zahni 554]

Da kenne ich dann wohl den SQL-Server von MS zu wenig. Bei DB2 wird für dynamischen SQL ein sog. Package erstellt, dass den Ausführungsplan enthält. Das kann über eine längere Zeit wiederverwendet werden. Static SQL (was Du vermutlich meinst) kann als "Package" dauerhaft an die Datenbank gebunden werden, wobei so ein Package  auch eine dynamische Komponente hat.

Denn eine DB lebt ja und optimale Ausführungspläne können sich ändern (angepasste Statistiken, neue Indizes, etc). 

In freier Wildbahn habe ich noch keine Anwendung gesehen, die STATIC SQL wirklich  benutzen. Die Entwickler können meisten nur "Hibernate" bedienen.

Sicher wird die geben, keine Frage. Der DBA kann in dem Bereich eh wenig "von sich aus" machen.

[Sunny61 806]

Ich kenn den DB2 Server nicht. ;)

 

Ein weiteres Plus für die SPs ist die Sicherheit, ein Benutzer braucht nur noch Ausführungsberechtigungen auf die SP, der Rest läuft dann innerhalb der SP ab.

http://de.wikipedia.org/wiki/Gespeicherte_Prozedur D.h. ich brauch nicht 'rumhampern' mit irgendwelchen Berechtigungen auf Tabellen, Views. Einfach nur die SP ausführen lassen, fertig. Hier findet sich auch noch ein bisschen Erklärung dazu: http://technet.microsoft.com/en-us/library/aa174792(v=sql.80).aspx

 

Aber es gibt hier sicherlich Mitglieder die das besser und fundierter erklären können. ;)

bearbeitet 20. November 2014 von Sunny61

[NilsK 2.934]

Moin,

 

Naja dann sollte man aber keine mit 7200RPM kaufen. ;)

 

oh, in einem Notebook wäre das schnell. ;)

 

Gruß, Nils