API-Leitfaden zu Steuerungs-Policys für Trafficmanagement

Mit der Oracle Cloud Infrastructure DNS-REST-API können Sie Trafficmanagement-Policys erstellen und konfigurieren.

Im folgenden Leitfaden finden Sie Informationen zum Erstellen von Policys mit der DNS-REST-API.

Authentifizierung und Autorisierung

Jeder Service in Oracle Cloud Infrastructure lässt sich mit IAM zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) integrieren.

Ein Administrator in einer Organisation muss Gruppen , Compartments und Policys einrichten, die steuern, welche Benutzer auf Services, Ressourcen und Zugriffstypen zugreifen können. Beispiel: Die Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und verwalten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen kann usw. Weitere Informationen finden Sie unter Identitätsdomains verwalten. Einzelheiten zum Schreiben von Policys für die einzelnen Services finden Sie in der Policy-Referenz.

Wenn Sie ein regulärer Benutzer sind (nicht ein Administrator), der die Oracle Cloud Infrastructure-Ressourcen verwenden muss, für die das Unternehmen verantwortlich ist, bitten Sie einen Administrator, eine Benutzer-ID für Sie einzurichten. Der Administrator kann festlegen, welche Compartments Sie verwenden können.

Steuerungs-Policy für Trafficmanagement - Komponenten

In der folgenden Liste werden die Komponenten beschrieben, die für das Erstellen einer Steuerungs-Policy für Trafficmanagement verwendet werden.

STEUERUNGS-POLICYS: Ein allgemeines Framework zum Definieren des Trafficmanagementverhaltens für Zonen. Steuerungs-Policys enthalten Regeln, mit denen DNS-Antworten auf intelligente Weise übermittelt werden können.
ANHÄNGE: Mit dieser Option können Sie eine Steuerungs-Policy mit Zonen verknüpfen. Ein Anhang einer Steuerungs-Policy zu einer Zone enthält alle Datensätze in ihrer Domain, die zu einem vertraglich abgedeckten Datensatztyp gehören, und erstellt DNS-Antworten aus ihrer Steuerungs-Policy und nicht aus den Datensätzen dieser Domain. Eine Domain kann höchstens einen Anhang aufweisen, der einen bestimmten Datensatztyp umfasst.
REGELN: Die Richtlinien, die von Steuerungs-Policys zum Filtern von Antworten verwendet werden, basierend auf den Eigenschaften einer DNS-Anforderung, wie der Geolokation der Anforderung oder dem Status von Endpunkten.
ANTWORTEN: Antworten enthalten die DNS-Datensatzdaten und Metadaten, die in einer Steuerungs-Policy verarbeitet werden sollen.
VORLAGEN: Vorlagen sind vordefinierte Regelfolgen, die einen Policy-Typ und sein gewünschtes Verhalten erstellen. Beispiel: Die Vorlage FAILOVER dient Antworten, indem zuerst die DNS-Abfrage mit einer FILTER Regel und dann die folgenden Regeln nacheinander geprüft werden: HEALTH, PRIORITY und LIMIT. Dadurch wird die dynamische Failover-Funktion für die Domain bereitgestellt. Policys, die das Feld template mit einer anderen Policy als CUSTOM definieren, müssen der für diesen Policy-Typ beschriebenen Regelfolge folgen. Andernfalls wird beim Erstellen der Policy ein 400 Statuscodefehler zurückgegeben.
FÄLLE: Eine Regel kann optional eine Sequenz von Fällen umfassen, die alternative Konfigurationen für das Verhalten bei der Verarbeitung für eine bestimmte DNS-Abfrage definieren. Wenn eine Regel keine Sequenz von Fällen aufweist, wird sie bei der Verarbeitung immer mit derselben Konfiguration ausgewertet. Wenn eine Regel eine leere Sequenz von Fällen aufweist, wird sie bei der Verarbeitung immer ignoriert. Wenn eine Regel eine nicht leere Sequenz von Fällen aufweist, wird ihr Verhalten bei der Verarbeitung durch den ersten übereinstimmenden Fall in der Sequenz konfiguriert. Ein Regelfall ohne caseCondition stimmt immer überein. Ein Regelfall mit einer caseCondition stimmt nur dann überein, wenn die Auswertung dieses Ausdrucks für die spezifische Abfrage "true" ergibt.

Steuerungs-Policys mit Vorlagen erstellen

Im folgenden Abschnitt wird die Regelkonfiguration für die einzelnen Steuerungs-Policy-Vorlagentypen erläutert, gefolgt von einem Beispiel für eine POST-Anforderung ( CreateSteeringPolicy). Hier ist dargestellt, wie die einzelnen Vorlagen konfiguriert werden.

FAILOVER

Benutzer-Failover-Policys zur Priorisierung der Reihenfolge, in der Antworten in einer Policy bereitgestellt werden (Beispiel: primär und sekundär). Oracle Cloud Infrastructure Health Checks Monitore und On-Demand-Probes werden verwendet, um den Zustand der Antworten in der Policy zu bewerten. Wird die primäre Antwort als fehlerhaft eingestuft, wird der DNS-Traffic automatisch an die sekundäre Antwort geleitet. Jede der folgenden Regeln muss in der Reihenfolge definiert werden, die im Feld rules des Anforderungsbodys angegeben ist, wenn eine FAILOVER-Vorlage verwendet wird:


Reihenfolge	Regel	Einschränkungen	Kommentare
`1`	`FILTER`	Keine Fälle sind zulässig. Antwortdaten müssen in `defaultAnswerData` mit der folgenden JSON definiert werden: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Keine Fälle sind zulässig.	Nur enthalten, wenn `healthCheckMonitorId` für die Policy definiert ist.
`3`	`PRIORITÄT`	Keine Fälle sind zulässig. Antwortdaten müssen in der Eigenschaft `defaultAnswerData` für die Regel definiert werden. Jede Antwort muss über eine Pooleigenschaft verfügen. `defaultAnswerData`-Einschränkungen: Antworten können nicht von ihrer Namenseigenschaft in `answerCondition`-Ausdrücken referenziert werden. Sie müssen von ihrer Pooleigenschaft referenziert werden. Jeder Antwortpool muss einmalig referenziert werden. PRIORITÄT PRIORITÄT
`4`	`LIMIT`	Keine Fälle sind zulässig.

Beispiel für eine POST /steeringPolicies-Policy, die mit der FAILOVER-Vorlage erstellt wurde:

{
  "compartmentId": "ocid1...",
  "displayName": "failover between endpoints",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "FAILOVER",
  "answers": [
    {
      "name": "server-primary",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "primary"
    },
    {
      "name": "server-secondary",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "secondary"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.pool == 'primary'",
          "value": 1
        },
        {
          "answerCondition": "answer.pool == 'secondary'",
          "value": 99
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

LOAD_BALANCE

Load Balancer Policys verteilen den Traffic auf viele Endpunkte. Sie können Endpunkten gleiche Gewichtungen zuweisen, um den Traffic gleichmäßig auf die Endpunkte zu verteilen, oder Sie können benutzerdefinierte Gewichtungen für das Verhältnis-Load Balancing zuweisen. Oracle Cloud Infrastructure Health Checks-Monitore und On-Demand-Probes werden genutzt, um den Zustand des Endpunkts zu bewerten. DNS-Traffic wird automatisch auf die anderen Endpunkte verteilt, wenn sich ein Endpunkt als ungesund herausstellt. Jede der folgenden Regeln muss in der Reihenfolge definiert werden, die im Feld rules des Anforderungsbodys angegeben ist, wenn eine LOAD_BALANCE-Vorlage verwendet wird:


Reihenfolge	Regel	Einschränkungen	Kommentare
`1`	`FILTER`	Keine Fälle sind zulässig. Antwortdaten müssen in `defaultAnswerData` mit der folgenden JSON definiert werden: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Keine Fälle sind zulässig.	Nur enthalten, wenn `healthCheckMonitorId` für die Policy definiert ist.
`3`	`GEWICHTET`	Keine Fälle sind zulässig. Antwortdaten müssen in der DefaultAnswerData-Eigenschaft für die Regel definiert werden. Antworten können nicht von ihrer Pooleigenschaft in answerCondition-Ausdrücken referenziert werden. Sie müssen von ihrer Namenseigenschaft referenziert werden.
`4`	`LIMIT`	Keine Fälle sind zulässig.

Beispiel für eine POST /steeringPolicies-Policy mit der LOAD_BALANCE-Vorlage:

{
  "compartmentId": "ocid1...",
  "displayName": "Weighted load balance for a set of answers with health checks",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "LOAD_BALANCE",
  "answers": [
    {
      "name": "server1",
      "rtype": "A",
      "rdata": "192.168.0.2"
    },
    {
      "name": "server2",
      "rtype": "A",
      "rdata": "192.168.0.3"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "WEIGHTED",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.name == 'server1'",
          "value": 99
        },
        {
          "answerCondition": "answer.name == 'server2'",
          "value": 1
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_GEO

Bei Geolokationssteuerungs-Policys wird der DNS-Traffic basierend auf dem Standort des Endbenutzers an verschiedene Endpunkte verteilt. Kunden können geografische Regionen aus Ursprungskontinent, -ländern oder -bundesstaaten/-provinzen (Nordamerika) sowie einen separaten Endpunkt oder ein Set aus Endpunkten für jede Region definieren. Jede der folgenden Regeln muss in der Reihenfolge definiert werden, die im Feld rules des Anforderungstextes angegeben wird, wenn eine ROUTE_BY_GEO-Vorlage verwendet wird:


Reihenfolge	Regel	Einschränkungen	Kommentare
`1`	`FILTER`	Keine Fälle sind zulässig. Antwortdaten müssen in `defaultAnswerData` mit der folgenden JSON definiert werden: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Keine Fälle sind zulässig.	Nur enthalten, wenn `healthCheckMonitorId` für die Policy definiert ist.
`3`	`PRIORITÄT`	Die Eigenschaft `defaultAnswerData` kann in dieser Regel nicht verwendet werden. Mindestens ein Fall muss definiert werden. Wenn es viele Fälle gibt, kann der letzte Fall einen "Catch-all"-Fall liefern. Die Eigenschaft `caseCondition` in Fällen kann `query.client.geoKey` nur im bedingten Ausdruck verwenden. Antworten können nicht von ihrer Namenseigenschaft in `answerCondition`-Ausdrücken referenziert werden. Sie müssen von ihrer Pooleigenschaft referenziert werden. Jede Antwort muss über eine Pooleigenschaft verfügen. Für jeden Fall `answerData`: Jeder Antwortpool muss einmal und nur einmal referenziert werden. Jeder Antwortpool muss eine eindeutige Werteigenschaft aufweisen (im Fall). Jede Antwortpoolreferenz muss mit der Pooleigenschaft auf einer oder mehreren Antworten übereinstimmen, die in der Antwortliste für die Policy definiert sind.
`4`	`LIMIT`	Keine Fälle sind zulässig.

Beispiel für einen POST /steeringPolicies-Anforderungsbody, der mit der ROUTE_BY_GEO-Vorlage erstellt wurde:

{
  "compartmentId": "ocid1...",
  "displayName": "Geolocations mapped to answer pools",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "ROUTE_BY_GEO",
  "answers": [
    {
      "name": "US Server 1",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "US"
    },
    {
      "name": "US Server 2",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "US"
    },
    {
      "name": "EU Server 1",
      "rtype": "A",
      "rdata": "192.168.0.4",
      "pool": "EU"
    },
    {
      "name": "EU Server 2",
      "rtype": "A",
      "rdata": "192.168.0.5",
      "pool": "EU"
    },
    {
      "name": "rest of world 1",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Global"
    },
    {
      "name": "rest of world 2",
      "rtype": "A",
      "rdata": "203.0.113.3",
      "pool": "Global"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.geoKey in (geoKey '6255149')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.geokey in (geokey '6255148')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_ASN

Mit ASN-Steuerungs-Policys können Sie DNS-Traffic basierend auf der Nummer des autonomen Systems (ASN) steuern. DNS-Abfragen von einer bestimmten ASN oder einem Set von ASNs können an einen bestimmten Endpunkt geleitet werden. Jede der folgenden Regeln muss in der Reihenfolge definiert werden, die im Feld rules des Anforderungstextes angegeben wird, wenn eine ROUTE_BY_ASN-Vorlage verwendet wird:


Reihenfolge	Regel	Einschränkungen	Kommentare
`1`	`FILTER`	Keine Fälle sind zulässig. Antwortdaten müssen in `defaultAnswerData` mit der folgenden JSON definiert werden: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Keine Fälle sind zulässig.	Nur enthalten, wenn `healthCheckMonitorId` für die Policy definiert ist.
`3`	`PRIORITÄT`	Die Eigenschaft defaultAnswerData kann in dieser Regel nicht verwendet werden. Mindestens ein Fall muss definiert werden. Wenn es viele Fälle gibt, kann der letzte Fall einen "Catch-all"-Fall liefern. Die caseCondition-Eigenschaft in Fällen kann query.client.asn nur im bedingten Ausdruck verwenden. Antworten können nicht von ihrer Namenseigenschaft in answerCondition-Ausdrücken referenziert werden. Sie müssen von ihrer Pooleigenschaft referenziert werden. LIMIT answerData für jeden Fall: Jeder Antwortpool muss einmal und nur einmal referenziert werden. Jeder Antwortpool muss eine eindeutige Werteigenschaft aufweisen (im Fall). Jede Antwortpoolreferenz muss mit der Pooleigenschaft in einer oder mehreren Antworten übereinstimmen, die in der Antwortliste für die Policy definiert sind.
`4`	`LIMIT`	Keine Fälle sind zulässig.

Beispiel für einen POST /steeringPolicies-Anforderungsbody, der mit der ROUTE_BY_ASN-Vorlage erstellt wurde:

{
  "compartmentId": "ocid1...",
  "displayName": "ASNs mapped to pools",
  "ttl": 30,
  "template": "ROUTE_BY_ASN",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.asn == 3",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.asn == 16591",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_IP

Bei IP-Präfixsteuerungs-Policys können Kunden den DNS-Traffic basierend auf dem IP-Präfix der Ursprungsabfrage steuern. Jede der folgenden Regeln muss in der Reihenfolge definiert werden, die im Feld rules des Anforderungstextes angegeben wird, wenn eine ROUTE_BY_IP-Vorlage verwendet wird:


Reihenfolge	Regel	Einschränkungen	Kommentare
`1`	`FILTER`	Keine Fälle sind zulässig. Antwortdaten müssen in `defaultAnswerData` mit der folgenden JSON definiert werden: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Keine Fälle sind zulässig.	Nur enthalten, wenn `healthCheckMonitorId` für die Policy definiert ist.
`3`	`PRIORITÄT`	Die Eigenschaft `defaultAnswerData` kann in dieser Regel nicht verwendet werden. Mindestens ein Fall muss definiert werden. Wenn es viele Fälle gibt, kann der letzte Fall einen "Catch-all"-Fall liefern. Die Eigenschaft `caseCondition` in Fällen kann Query.client.address nur im bedingten Ausdruck verwenden. Antworten können nicht von ihrer Namenseigenschaft in `answerCondition`-Ausdrücken referenziert werden. Sie müssen von ihrer Pooleigenschaft referenziert werden. Jede Antwort muss über eine Pooleigenschaft verfügen. Für jeden Fall `answerData`: Jeder Antwortpool muss einmal und nur einmal referenziert werden. Jeder Antwortpool muss eine eindeutige Werteigenschaft aufweisen (im Fall). Jede Antwortpoolreferenz muss mit der Pooleigenschaft auf einer oder mehreren Antworten übereinstimmen, die in der Antwortliste für die Policy definiert sind.
`4`	`LIMIT`	Keine Fälle sind zulässig.

Beispiel für einen POST /steeringPolicies-Anforderungsbody, der mit der ROUTE_BY_IP-Vorlage erstellt wurde:

{
  "compartmentId": "ocid1...",
  "displayName": "IP subnets mapped to answer pools",
  "ttl": 30,
  "template": "ROUTE_BY_IP",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.address in (subnet '10.0.3.0/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.address in (subnet '192.0.2.2/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

BENUTZERDEFINIERT

Verwenden Sie benutzerdefinierte Policys, um komplexe Policys zu erstellen, in denen Sie die Funktionen von Failover, Load Balancing, Geolocation-, ASN- und IP-Präfixsteuerung kombinieren. Benutzerdefinierte Vorlagen erfordern keine festgelegte Sequenz von Regeln. Wir empfehlen Ihnen, sich vor der Erstellung einer benutzerdefinierten Policy an den Oracle Cloud Infrastructure-Support zu wenden.

Regeltypen

FILTER: Verwendet mit Antworten verknüpfte boolesche Daten und behält Antworten nur bei, wenn der Wert shouldKeep für die Regel auf true gesetzt ist.
HEALTH: Verwendet OCI Health Checks-Monitore und On-Demand-Probes, um den Zustand von Endpunkten zu bewerten und bei Bedarf Antworten aus der Policy hinzuzufügen und zu entfernen. Ein Health-Check-Monitor muss in einer Zustandsregel referenziert werden, damit er sich auf die Policy auswirkt. Weitere Informationen zu Health Checks finden Sie unter Health Checks.
GEWICHTUNG: Bewertet mit einer Zahl zwischen 0 und 255, wie oft eine Antwort in Bezug auf andere Antworten bereitgestellt wird. Antworten mit höheren Werten werden mit höherer Wahrscheinlichkeit zurückgegeben.
PRIORITÄT: Verwendet eine Ganzzahl, die mit jeder Antwort verknüpft ist, um die Antworten von der niedrigsten bis zur höchsten Priorität zu sortieren. Beispiel: Eine Antwort mit dem Prioritätswert 1 wird vor einer Antwort mit dem Prioritätswert 10 in der Antwortliste zurückgegeben. Antworten, denen keine Priorität zugewiesen ist, werden an das Ende der Antwortliste verschoben.
LIMIT: Verwendet eine Count-Eigenschaft, um alle außer den ersten Antworten in der Liste herauszufiltern.

Oracle Cloud Infrastructure - Dokumentation