Grundsätzlich - kann DB mehrere Indizes kombinieren?

[BlackbirdBerlin]

Hi Otto,

das Problem beim Mal-Eben-Testen ist, dass selbst die QS in einer Hochverfügbarkeitsumgebung läuft, weil da viele Projekte parallel laufen und mal eben einen Index für knapp 200 Mio Datensätze anlegen oder drei Testtabellen ins System kippen und damit zig ( oder mehr ) Leute bis zur Behebung des Problems arbeitsunfähig machen, geht leider nicht.
In einer "eigenen" Umgebung solche Tests fahren, ist natürlich kein Problem. Aber da hat man eben nicht die Gewissheit, dass die Systemumgebung und die Datenkonstellation zu dem gleichen Ergebnis führen.

Viele Grüße
Tim

[mm1256]

Zitat von BlackbirdBerlin:

In einer "eigenen" Umgebung solche Tests fahren, ist natürlich kein Problem. Aber da hat man eben nicht die Gewissheit, dass die Systemumgebung und die Datenkonstellation zu dem gleichen Ergebnis führen.

Ich habe natürlich "eigene Umgebung" gemeint.

Bitte korrigiere mich, wenn ich da etwas falsch sehe:

Systemumgebung: Auch wenn die DB auf deinem eigenen Test-Server mit anderer Hardware läuft, sollten zuverlässige Ergebnisse möglich sein. Dass die Ergebnisse/Zeiten natürlich von der realen Umgebung beim Kunden abweichen, ist mir schon klar. Die Relation der Unterschiede untereinander dürfte jedoch eindeutig zu erkennen sein. Und darum geht es doch letzendlich. Wenn die Query-Zeiten ohne Index und mit Index z.B. im Verhältnis 10:3 wären, dann können die Unterschiede zur Systemumgebung des Kunden nicht ausschlaggebend sein. Denn ob es beim Kunden dann 10:5 oder 10:2 wäre, ist unerheblich. Die Steigerung wäre enorm. Etwas anders sieht es aus, wenn das Verhältnis nahezu gleich wäre. Aber auch dann hast du wenigstens einen Anhaltspunkt, was Sache ist.

Datenkonstellation: Wenn kein Join involviert ist...

Zitat von BlackbirdBerlin:

Es handelt sich um keinen Join sondern um eine einfache Tabelle, zu welcher bisher das für meinen Zugriff erforderliche Schlüsselfeld nicht indiziert ist.

...dürfte das auch kein Problem sein.

[jobo]

Zitat von mm1256:

..
Bitte korrigiere mich, wenn ich da etwas falsch sehe:

Systemumgebung: Auch wenn die DB auf deinem eigenen Test-Server mit anderer Hardware läuft, sollten zuverlässige Ergebnisse möglich sein. Dass die Ergebnisse/Zeiten natürlich von der realen Umgebung beim Kunden abweichen, ist mir schon klar. Die Relation der Unterschiede untereinander dürfte jedoch eindeutig zu erkennen sein. Und darum geht es doch letzendlich. ..

Ja, darum geht es primär und das kann man testen, auch in Relation.

Ich würde aber ergänzen:
Der springende Punkt bei solchen Systemen ist, dass sie idR einer Fülle von anderen Anforderungen- von OLTP bis ggF. Reporting- ausgesetzt sind, dass sie über Monate bis Jahre getuned und optimiert wurden und zwar bis in die Formulierung einzelner Abfragen hinein. Und das sehr wahrscheinlich zu einem guten Teil mit einem empirischen Vorgehen, sprich "nicht nachvollziehbar". Status Quo im Produktivsystem ist dann einfach, dass es eben läuft. Und das lässt man nicht gern fahren für einen blöden Index von einem Externen für einen Report, den kein einziger Manager braucht.
Das Risiko ist einfach, dass das System bei irgendwelchen zuvor harmlosen Abfragen kippt und steht.

Das bedeutet am Ende, die Änderung mag für sich Sinn machen und funktionieren und fürchterlich viel Speed bringen für die Abfrage. Wie aber reagiert der Rest des Systems? Das kann ich nur in einem Echtsystem feststellen in dem ein Arbeitstag, eine Arbeitswoche, ein Abschluss, etc pp durchgeorgelt wird.