5.0 Update 1 (Build 25359) - Vorteile und Gefahren
3. Januar 2008 17:00
Im Forum ist dies schon mehrfach angesprochen worden, aber ich finde, es fehlt hier einfach ein zusammen fassendes Thema (dessen Antworten ich "rein zufällig" jetzt brauche 
):
5.0 Update 1 - lohnt sich das Upgrade? Was verbessert wurde, kann ich im KB Artikel nachlesen.
Was waren noch einmal die Nachteile? Worauf müsste ich achten?
):
5.0 Update 1 - lohnt sich das Upgrade? Was verbessert wurde, kann ich im KB Artikel nachlesen.
Was waren noch einmal die Nachteile? Worauf müsste ich achten?
3. Januar 2008 17:28
Im Moment scheint der einzige Nachteil zu sein, dass der NAS beim Beenden eine Latte Fehlermeldungen wirft, die aber die Funktion ansonsten nicht beeinträchtigen.
Nötig ist das Update in jedem Fall, wenn du mit Umlauten und Sonderzeichen im XML-Port arbeiten musst. Sonst ist es aber wohl zumindest empfehlenswert, da bei den SIFTs ja wohl ein paar mögliche Fehler beseitigt wurden.
Nötig ist das Update in jedem Fall, wenn du mit Umlauten und Sonderzeichen im XML-Port arbeiten musst. Sonst ist es aber wohl zumindest empfehlenswert, da bei den SIFTs ja wohl ein paar mögliche Fehler beseitigt wurden.
16. Januar 2008 15:02
Haben die anderen keine Meinung/Wissen dazu?
Irgend jemand hatte doch wegen Index Hinting laut aufgeschrien, oder hab ich da was verwechselt?
Irgend jemand hatte doch wegen Index Hinting laut aufgeschrien, oder hab ich da was verwechselt?
16. Januar 2008 15:36
Nein, da hast Du nichts verwechselt. IndexHinting ist jetzt standardnäßig eingeschaltet, es sei denn, es wird abgeschaltet per SQL-Script.
Siehe Links
- http://www.msdynamics.de/viewtopic.php? ... dexhinting
- http://www.msdynamics.de/viewtopic.php? ... dexhinting
Ein weitere Vorteil ist, dass sich SIFT nicht mehr verrechnet.
Siehe Links
- http://www.msdynamics.de/viewtopic.php? ... dexhinting
- http://www.msdynamics.de/viewtopic.php? ... dexhinting
Ein weitere Vorteil ist, dass sich SIFT nicht mehr verrechnet.
16. Januar 2008 15:39
Das hilft mir leider als SQL-Laie nicht weiter...
Ist es nun ein Vor- oder Nachteil für mich, wenn IndexHinting standardmäßig eingeschaltet ist? Warum, und worin äußert sich dies bei der Anwendung?
Ist es nun ein Vor- oder Nachteil für mich, wenn IndexHinting standardmäßig eingeschaltet ist? Warum, und worin äußert sich dies bei der Anwendung?
16. Januar 2008 15:44
Wenn IndexHinting verwendet wird, nimmt der SQL-Server immer den Index, der per SETCUURENTKEY vorgegeben wurde. Der Query Optimizer kann dann nicht auf einen besseren bzw. schnelleren ausweichen.
Wenn IndexHinting für die gesamte Datenbank immer global eingeschaltet ist, kann sich das ganze als Performanz-Nachteil erweisen, da der beste NAV-Schlüssel nicht immer des beste SQL-Index ist.
EDIT: Für einzelne und spezielle Queires kann sich IndexHinting als großer Vorteil erweisen.
Wenn IndexHinting für die gesamte Datenbank immer global eingeschaltet ist, kann sich das ganze als Performanz-Nachteil erweisen, da der beste NAV-Schlüssel nicht immer des beste SQL-Index ist.
EDIT: Für einzelne und spezielle Queires kann sich IndexHinting als großer Vorteil erweisen.
16. Januar 2008 15:51
Ah, OK,
das heißt: Wenn ich aber bewusst in NAV meine Schlüssel wähle (erste Felder im Schlüssel möglichst vom Typ Code; boolean und Option möglichst ganz hinten oder gar nicht), dann werde ich keine großen Einbußen haben?
Was ich leider noch nicht weiß: Wie gut oder schlechte hantiert der NAV-Standard mit den Schlüsseln ...
Und wenn per Code GAR kein Schlüssel gesetzt ist - wird wieder der Query Optimizer eingesetzt oder wird nach dem Primärschlüssel sortiert?
Alternativ: Ist es als Laie ein großer Aufwand, IndexHinting zu deaktivieren? Die Anleitungen habe ich schon mal grob überflogen - aber welcher Aufwand steckt wirklich dahinter?
das heißt: Wenn ich aber bewusst in NAV meine Schlüssel wähle (erste Felder im Schlüssel möglichst vom Typ Code; boolean und Option möglichst ganz hinten oder gar nicht), dann werde ich keine großen Einbußen haben?
Was ich leider noch nicht weiß: Wie gut oder schlechte hantiert der NAV-Standard mit den Schlüsseln ...
Und wenn per Code GAR kein Schlüssel gesetzt ist - wird wieder der Query Optimizer eingesetzt oder wird nach dem Primärschlüssel sortiert?
Alternativ: Ist es als Laie ein großer Aufwand, IndexHinting zu deaktivieren? Die Anleitungen habe ich schon mal grob überflogen - aber welcher Aufwand steckt wirklich dahinter?
16. Januar 2008 16:00
Der Query Optimizier läuft permanent mit. Bei IndexHinting darf er nur nicht zu Tate schreiten.
Wenn per Code kein Key gesetzt wurde, wird der Primärschlüssel verwendet. Der bewusst gesetzte Key muss nicht immer der Beste sein, da NAV auf manche Sortierungen angewiesen ist.
Es gibt einen kleinen Unterschied zwischen SQL-Index und NAV-Key:
Ein Index hat ein etwas anderes Konzept als ein Key. Ein Index wird primär zur Datensatzfindung in Binären Bäumen und nicht zur Sortierung genutzt. Die Sortierung geschieht im SQL-Server ggf. im Speicher. Ein Key in NAV wird überwiegend zur Sortierung genutzt.
Ich würde die Alternative SQL-Script nehmen und IndexHinting Global deaktivieren. Per Enterprise Manager/SQL Mgt. Studio das Script laufen lassen dauert nicht lange.
Wenn per Code kein Key gesetzt wurde, wird der Primärschlüssel verwendet. Der bewusst gesetzte Key muss nicht immer der Beste sein, da NAV auf manche Sortierungen angewiesen ist.
Es gibt einen kleinen Unterschied zwischen SQL-Index und NAV-Key:
Ein Index hat ein etwas anderes Konzept als ein Key. Ein Index wird primär zur Datensatzfindung in Binären Bäumen und nicht zur Sortierung genutzt. Die Sortierung geschieht im SQL-Server ggf. im Speicher. Ein Key in NAV wird überwiegend zur Sortierung genutzt.
Ich würde die Alternative SQL-Script nehmen und IndexHinting Global deaktivieren. Per Enterprise Manager/SQL Mgt. Studio das Script laufen lassen dauert nicht lange.