Hallo,

ich hoffe mir kann hier jemand helfen. Wir haben auf einem Entwicklungssystem unter anderen zwei Tabellen deren Schlüssel sich über 13 Spalten erstreckt (möglich sind angeblich bis zu 15) und eine Länge von 120 Zeichen überschreitet (ergibt eine Warnung bei der Konsistenzprüfung).

Eigentlich sollte dies kein Problem sein. Auf Systemen beim Kunden treten auch keine Probleme auf. Bei uns allerdings benötigt z.B. die SE11 deutlich über 30 Sekunden, um eine dieser Tabellen mit gerademal 220 Einträgen durchzuzählen.

Gibt es einen Systemparameter, ein Support Package oder ähnliches, welches hier Abhilfe schaffen kann?

Danke und Grüße,

R. Unverzagt

Hallo R. Unverzagt,

ich glaube nicht, daß es hier einen Patch o. ä. gibt, der das Problem beheben kann. Vielmehr sehe ich hier ein methodisches Problem:

Theoretisch ist es sicher möglich, in einem Schlüssel bis zu 15 Spalten unterzubringen. Da zu einem Schlüssel normalerweise ein Index gehört (z. B. wird beim Erstellen von Primärschlüsseln immer ein Index erzeugt), ist auch dieser entsprechend breit. Nicht nur, daß das auch die Datenbank vergrößert - dies ist das kleinere Problem. Viel schlimmer ist, daß der Abfrage-Optimizer mit solch breiten Schlüsseln/Indizes nicht umgehen kann. Der Zustand auf Eurem Testsystem ist offenbar ein anschauliches Beispiel dafür, wenn nur das Zählen der 220 Sätze schon 30 Sekunden dauert.

Wenn auf den Kundensystemen ebenfalls solche breiten Indizes existieren, dann ist es einfach Glück, daß der Optimizer diese Schlüssel für die Abfragen nicht auswählt. Eventuell kommen gar keine Abfragen, die zu diesen Schlüsseln passen.

Je schmaler der Index (dessen Schlüssel zur where-Bedingung der Abfrage passen muß, um ausgewählt zu werden), desto günstiger und schneller wird die Abfrage ausgeführt. Ich würde versuchen, die SQL-Abfragen so zu gestalten, daß ein Index mit 1-3 Spalten reicht.

Übrigens, nicht nur die Breite eines Indexes ist für die Performance des Systems ausschlaggebend, sondern auch die Anzahl der Schlüssel, die auf einer Tabelle liegen. Der Optimizer muß ja auch entscheiden, welchen Schlüssel er anwendet. Je mehr Schlüssel auf einer Tabelle liegen, desto größer ist die Wahrscheinlichkeit, daß der falsche Schlüssel ausgewählt wird. Auch hier gilt m. E. der Bereich 1-3 Schlüssel je Tabelle. Bei größeren Anzahlen wird man mitunter schon entsprechend experimentieren müssen, inwieweit das Anlegen eines weiteren Schlüssels Auswirkungen auf bisher funktionierende Abfragen hat.

Insgesamt ist das Thema Datenbank-Schlüssel kein einfaches Thema. Das Ergebnis, das man sich von einem Schlüssel erhofft, tritt nicht immer ein.

Ich hoffe, meine Antwort hilft ein wenig weiter.

Grüße von Jörg.

Hallo piijobr,

danke für die Antwort.

In den Kundensystemen kommt es definitiv zu Abfragen auf diese Tabellen. Dieselbe Tabelle mit derselben Transaktion mit derselben Anzahl Einträge  im Kundensystem durgezählt benötigt nur Sekundenbruchteile.

Die breiten Schlüssel sind für das Modul laut Entwickler nötig.

Eines hat mich allerdings hellhörig weren lassen: Abfrage-Optimizer!

Das habe ich bislang nicht gehört. Gibt es eine Transaktion, einen Report, Datenbankparameter, o.ä. mit der dieser konfiguriert werden kann?

Wenn man verbieten könnte, dass bei "langen" Schlüsseln optimiert wird sollte die Abfrage doch schneller gehen, oder?

Nochmals danke,

runverzagt

Hallo R. Unverzagt,

also in der Beziehung ist mir nichts bekannt, daß man am Abfrage-Optimizer etwas ändern kann/sollte. Es handelt sich dabei ja um einen Teil des Datenbanksystems, und man "konfiguriert" ihn durch Erstellen von Schlüsseln/Indizes. Und man kann ihn durch Anlegen ungünstiger, zu vieler oder zu breiter Schlüssel gehörig durcheinander bringen. Auch andere Faktoren, wie die Anzahl von Datensätzen beeinflußt die Arbeitsweise des Optimizers.
Wenn es denn überhaupt möglich ist, die Arbeitsweise der DB an dieser Stelle zu beeinflussen, dann ist das sicher DB-abhängig und außerdem "Hohe Schule".

Eine Möglichkeit gibt es allerdings schon; es handelt sich da um eine Art Dienstleistung, die der Mensch gegenüber seinem DB-System eventuell regelmäßig erbringen muß:
Es gibt hauptsächlich zwei verschiedene Arten von Abfrage-Optimizern:
- regelbasierte und
- kostenbasierte
Optimizer. Das ist vom Datenbanksystem abhängig: Oracle setzt einen regelbasierten, Informix bspw. einen kostenbasierten Optimizer ein.
Bei kostenbasierten Optimizern ist es häufiger nötig, ein UPDATE STATISTICS (auf SQL-Ebene) durchzuführen, damit die angelegten Indizes überhaupt passend angewendet werden können. Meistens werden solche Jobs in SAP-Systemen bzw. vom DB-System standardmäßig eingeplant. Vielleicht passiert das ja auf dem Testserver gar nicht (???).

Ich denke, der Grund dafür, daß das Performanceproblem auf den Kundensystemen nicht auftritt, liegt einfach darin, daß dort der jeweilige Abfrage-Optimizer den zu langen Schlüssel nicht auswählt. Die Ursache dafür wiederum kann darin liegen, daß auf der Tabelle noch andere Schlüssel liegen, die auf Kunden- und Testsystem vielleicht nicht identisch sind, so daß der Optimizer vielleicht einen anderen Schlüssel wählt.

Eine weitere Möglichkeit der Erklärung wäre diese: Wenn in der betreffenden Tabelle vorher eine große Anzahl von Datensätzen enthalten war, dann der Schlüssel/Index angelegt wurde, und danach ein großer Teil der Datensätze gelöscht wurde, so ist der Index jetzt eventuell stark fragmentiert. Dann sollte man ihn löschen und neu anlegen (se11, Hilfsmittel, DB-Utility).

Nach wie vor bin ich der Ansicht, daß ein Tabellenschlüssel, der über 13 Spalten geht, zu breit ist.

Vielleicht bringt's ja etwas: UPDATE STATISTICS und/oder Index löschen/neu anlegen. Vorher würde ich mich immer vergewissern, ob meine Datensicherung i.O. ist.
Viel Erfolg!

Gruß Jörg

Hallo Jörg,

danke noch einmal. Ich schaue mir grade alle Datenbankparameter an, welche dieses Verhalten beeinflussen könnten.

Jetzt habe ich zumindest einen Anhaltspunkt für die bislang unerklärlichen Probleme.

Danke,

R. Unverzagt

Hallo,

für alle, die sonst noch das Problem haben:

Die Lösung für das Problem ist in Hinweis 771929 zu finden. ALTER INDEX .... REBUILD ONLINE war sehr hilfreich.

Viele Grüße