Wie können Oracle-Benutzerprofile praktisch genutzt werden?

Question

Oracle 10g verfügt über Profile, mit denen verschiedene Ressourcen begrenzt werden können. Hier sind einige Verweise auf Klarheit - orafaq.com, Oracle Documentation. Ich bin besonders daran interessiert, CPU_PER_CALL, LOGICAL_READS_PER_CALL und COMPOSITE_LIMIT mit dem Ziel zu begrenzen, zu verhindern, dass eine schlecht gebildete Aussage die Leistung für jede andere Sitzung zerstört.

Mein Problem ist, dass ich nicht weiß, welche Werte für diese Parameter verwendet werden, die Ihre typischen lang laufenden ressourcenintensiven Operationen ermöglichen und gleichzeitig die wirklich schlechten verhindern. Ich bin mir bewusst, dass die Werte je nach Hardware, Toleranz und Abfragen variieren. Aus diesem Grund interessiere ich mich mehr für eine Methode, um zu bestimmen, welche Werte am besten sind.

Answer 1

Es gibt eine Vielzahl von Ansätzen, abhängig von der Situation. Der einfachste mögliche Ansatz, der jede Hoffnung auf Arbeit hat, ist die Frage, wie lange die am längsten laufende realistische Operation laufen würde (das hängt offensichtlich vom System ab und hängt davon ab, ob es sich um ein System handelt, das man gerade baut oder etwas gibt) ein CPU_PER_CALL basierend auf diesem Zeitlimit und dem Grad der Parallelität. Unter der Annahme einer Singlethread-Operation können Sie, wenn Sie vernünftigerweise sagen können, dass eine Abfrage nicht innerhalb von 30 Minuten zurückgegeben wurde, sie beenden möchten, CPU_PER_CALL so einstellen, dass sie 30 Minuten CPU-Leistung zuweist (offensichtlich verwenden die meisten Abfragen nicht 100 % konstant, so dass 30 Minuten Limit Ihnen etwas Raum zum Atmen gibt).

Wenn dies ein bestehendes System ist, können Sie (oder Ihr Datenbankadministrator) für eine angemessene Anzahl von Tagen AWR-/Statistik-Berichte durchsehen (einige Systeme müssen Berichte von Monat/Quartal/Ende des Berichts überprüfen) wo zusätzliche Verarbeitung durchgeführt werden kann) und finden Sie die realen Aussagen, die die meisten CPU und I/O verwenden. Sie können dann Ihre Profilgrenzen entsprechend einstellen (d. H. Die maximale CPU, die für eine Aussage im letzten Monat aufgezeichnet wurde + 30% des Atemraums).

Natürlich muss jemand für jedes Limit, das Sie auswählen, das System überwachen, um sicherzustellen, dass die Grenzwerte eingehalten werden. Wenn Abfragen im Laufe der Zeit immer teurer werden, weil beispielsweise das Datenvolumen steigt, ist es möglich, dass die Obergrenze von 30% in 6 Monaten nicht ausreicht. Sie wollen das nicht herausfinden, wenn die nächtliche Verarbeitung abbricht, jemand muss sich darüber halten.

Wenn Sie die Enterprise-Edition verwenden, können Sie besser Ressourcen-Manager als Profile betrachten. Mit Profilen können Sie Runaway-Sitzungen beenden, während Sie mit Resource Manager die Sitzungspriorität anhand verschiedener Faktoren ändern können. Anstatt eine Abfrage zu löschen, die mehr als 30 Minuten CPU verbraucht hat, ist es besser, sie niedriger zu priorisieren, damit sie andere Sitzungen nicht stört, ohne sie zu löschen, falls sie nur lange läuft.