Fehlerbehebung IBM DataStage

Hilfe und Unterstützung erhalten für DataStage

Wenn Sie Probleme oder Fragen bei der Nutzung haben DataStage, können Sie Hilfe erhalten, indem Sie nach Informationen suchen oder Fragen in einem Forum stellen. Sie können auch ein Support-Ticket öffnen.

Wenn Sie eine Frage in den Foren stellen, versehen Sie Ihre Frage mit einem Tag, damit sie von den DataStage Entwicklungsteams gesehen wird.

Bei Fragen zum Service und zu den ersten Schritten nutzen Sie bitte das Forum unter https://stackoverflow.com/questions/tagged/datastage.

Allgemein

• Aufträge schlagen mit der Fehlermeldung „Ressource vorübergehend nicht verfügbar“ fehl.
• Jobs schlagen fehl, weil SQL- und Before SQL-Anweisungen in falscher Reihenfolge ausgeführt werden.
• Der Befehl „mailx“ kann in den Unterprogrammen „before-job“ und „after-job“ ohne SMTP-Serverinformationen nicht ausgeführt werden.
• Die Eigenschaftenauswahl wird nicht beibehalten, wenn Sie „Eigenschaften DataStage verwenden“ deaktivieren.
• Die Routine schlägt fehl, wenn die CEL-Funktion auf einem externen ds.getUserStatus Fluss ausgeführt wird.
• Der Job schlägt beim Laden einer großen Excel-Datei fehl.
• Komponente kann nach DataStage Stromausfall nicht hinzugefügt werden
• Die Zusammenstellung des DataStage Flows schlägt fehl, wenn der Java-Klassenpfad parametrisiert ist.
• Exportierte Flows generieren JSON-Verbindungsdateien, die Klartext-Passwörter enthalten.
• Probleme beim Durchsuchen von Datenbanktabellen mit Spalten, die Sonderzeichen enthalten
• Falsche Ableitungen, die einem vom Asset-Browser gelesenen Schema zugewiesen wurden
• Sequenzielle Dateien als Quelle verwenden
• Fehler beim Ausführen von Jobs mit einem Dateiformat 'Parquet'
• Migrations-Pod wird wegen Überschreitung seiner temporären Speichergrenzen entfernt
• Beim Upgrade von Version Cloud Pak for Data 5.0.1 auf 5.0.0 tritt ein Fehler auf.
• Die Zusammenstellung eines Flusses, der die Transformatorstufe enthält, ist abgelaufen.
• Die Nutzung des temporären lokalen Speichers überschreitet das Gesamtlimit eines Containers.

Connectors

• Netezza® Connector: Doppelte Datensätze treten auf, wenn partitionierte Lesevorgänge aktiviert sind.
• MySQL Connector: Jobs können fehlschlagen, wenn Sie den Schreibmodus „Update“ für das Ziel ohne Primärschlüssel verwenden.
• FTP-Connector: Der Pfad zum Home-Verzeichnis wird dem Pfad vorangestellt.
• Jobs schlagen mit dem Fehler „Der Connector konnte keine Verbindung zur Db2® Datenbank herstellen“ fehl.
• Job mit Quelldaten aus einem SAP OData Konnektor schlägt fehl
• Transaktionales SQL kann nicht für Daten aus Apache Hive Version 2.0 oder früher ausgeführt werden.
• Db2IBM Die DataStage Verbindung mit dem SSL-Zertifikat schlägt mit dem Fehler „Protokollspezifischer Fehlercode 414” fehl.
• Fehler beim Parametrisieren des Felds „Anmeldeinformationen“ für eine Flussverbindung in IBM Cloud® Object Storage
• PostgreSQL Der Connector läuft bei großen Tabellen ab.
• Jobs mit einer Apache Hive Verbindung, für die die Erkennung ZooKeeper aktiviert ist, schlagen fehl.
• Schemaänderungen, die aus Daten des HTTP Konnektors stammen, können zum Fehlschlagen des Auftrags führen.
• Daten aus dem generischen JDBC Konnektor können nicht in der Vorschau angezeigt werden.
• Es kann keine erfolgreiche Datenbankverbindung unter Verwendung des SSL-Zertifikats hergestellt werden.
• Snowflake Anschluss: Jobs schlagen mit "java/lang/OutOfMemoryError" Fehler fehl
• Snowflake Connector: Jobs schlagen mit der Fehlermeldung „Fork fehlgeschlagen: Ressource vorübergehend nicht verfügbar“ fehl.
• Der Speicher-Volumen-Connector verursacht einen Zeitüberschreitungsfehler, wenn große Datenmengen geschrieben werden.

Laufzeit

• Große ISX-Importe verursachen Gateway-Zeitüberschreitungen und Kompilierungsfehler.
• Speicherplatzproblem für den DataStage Operator
• Jobs werden in eine Warteschlange gestellt, wenn Compute-Pods nicht gestartet werden können.
• Änderungen am Nachrichtenhandler werden nicht auf einen Joblauf angewendet.
• Jobwarteschlange
• Jobwarteschlange
• Container-Pods neu starten
• Eine PXRruntime-Instanz, die an einem physischen Standort bereitgestellt wird, kann nicht angezeigt werden.
• Keine vorhandenen Jobs bleiben hängen oder werden im Status „Startet“ oder „Läuft“ angezeigt.
• Synchronisationsfehler zwischen Pods mit gemountetem NFS Pfad in PXRuntime
• DataStage Update einschließlich erzwungenem Update wird aufgrund eines festgefahrenen PXRuntime blockiert

ds-Metriken

• Ausführung von ds-metrics auf FIPS-Clustern für 5.0.3 Version schlägt fehl
• DS-Metriken können nicht aktiviert werden. FIPS-tolerante oder FIPS-fähige Cluster für 5.1.0 Version
• Job_run_log speichert nur Log-Meldungen, die nicht zur INFO-Ebene gehören
• Die Metrikdatenbank kann nach dem Löschen des Schemas „ds_metrics“ nicht vollständig gelöscht werden.
• ds-metrics zeigt kurze Fehlermeldungen in den Service-Protokollen an

Allgemein

Konnektoren

Snowflake Anschluss: Jobs schlagen mit "java/lang/OutOfMemoryError" Fehler fehl

Das Protokoll zeigt die folgende Fehlermeldung an:

java/lang/OutOfMemoryError", exception "Failed to create a thread: retVal -1073741830, errno 11"

Workaround : Erhöhen Sie die Heap-Größe auf der Registerkarte „Ausgabe“ oder „Eingabe“ für Ihren Snowflake Connector.

Snowflake Connector: Jobs schlagen mit der Fehlermeldung „Fork fehlgeschlagen: Ressource vorübergehend nicht verfügbar“ fehl

Das Protokoll zeigt die folgenden Fehlernachrichten an:

<SCLoadAudIdLd.sf_write__JOB_EXECUTION_LOG__Ins,1> Error: Unable to create iprofiler thread11/6/2024 06:13:03 WARNING IIS-DSEE-USBP-00002 <Sf_STG_VEH_ALFA,0> Error: Unable to create iprofiler thread

und

WARNING IIS-DSEE-USBP-00002 <sc_AFT_COST_CENTRE_CD.sf_write__AUTO_FINANCE_TYPE__Ins,1>
Type=Segmentation error vmState=0x00000000
WARNING IIS-DSEE-USBP-00002 <sc_AFT_COST_CENTRE_CD.sf_write__AUTO_FINANCE_TYPE__Ins,1> J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001

Workaround : Erhöhen Sie die PID-Limits innerhalb des OpenShift Clusters. Setzen Sie podsPIDLimit auf 16,384, den Maximalwert für PID-Grenzwerte. Informationen zum Erhöhen der PID-Limits finden Sie im Kundenportal „ Red Hat “.

Der Speicher-Volumen-Connector verursacht einen Zeitüberschreitungsfehler, wenn große Datenmengen geschrieben werden

Die Dateien werden erfolgreich auf dem Speichermedium erstellt, aber es tritt ein Zeitüberschreitungsfehler auf.

Workaround : Mounten Sie das PVC auf die PX-Laufzeitinstanz und verwenden Sie den sequenziellen Dateikonnektor, um direkt in das gemountete PV zu schreiben, anstatt die Speicher-Volume-Verbindung zu verwenden.

Laufzeit

Große ISX-Importe verursachen Gateway-Zeitüberschreitungen und Kompilierungsfehler

Das Importieren einer großen ISX-Datei kann zu Gateway-Zeitüberschreitungsfehlern führen, und das Importieren einer Datei mit vielen Build-Stufen kann aufgrund fehlender Ressourcen zu Kompilierungsfehlern führen.

Workaround : Ändern Sie die Konfigurationen für DataStage und, px-runtime um mehr Ressourcen zuzuweisen. Siehe die folgenden empfohlenen benutzerdefinierten Konfigurationen.

Weitere Informationen finden Sie unter Ressourcen anpassen.

Weitere Informationen finden Sie unter „Anpassen von Ressourcen in DataStage.“

Bearbeiten Sie die DataStage benutzerdefinierte Ressource, um die Migrationsressourcen zu ändern:

oc edit datastage datastage -n ${PROJECT_CPD_INST_OPERANDS}

Fügen Sie im Abschnitt „spec:“ der YAML-Datei den folgenden Inhalt hinzu:

spec:
  custom:
    resources:
      components: 
        migration:
          replicas: 1
          limits:
            cpu: "6"
            memory: 20Gi
          requests:
            cpu: "2"
            memory: 6Gi

Aktualisieren Sie die PXRuntime-Ressourcen:

# retrieve pxruntime cr
oc -n ${PROJECT_CPD_INST_OPERANDS} get pxruntime

Bearbeiten Sie die benutzerdefinierte Ressource:

oc -n ${PROJECT_CPD_INST_OPERANDS} edit pxruntime <cr-name>

Fügen Sie im Abschnitt „spec:“ der YAML-Datei den folgenden Inhalt hinzu:

spec:
  custom:
    resources:
      components:
        pxruntime:
          limits:
            cpu: "4"
            memory: 8Gi
          requests:
            cpu: "2"
            memory: 2Gi

Speicherplatzproblem für den DataStage Operator

Wenn mehr als 5 PX-Laufzeitinstanzen auf dem Cluster bereitgestellt werden, kann es vorkommen, dass dem Betreiber der Arbeitsspeicher ausgeht. Um dieses Problem zu beheben, aktualisieren Sie die CSV-Datei, um die Speichergrenzen zu erhöhen:

CSV DataStage abrufen:

oc -n ${PROJECT_CPD_INST_OPERATORS} oc get csv | grep datastage

Patch die DataStage CSV-Datei, um den Arbeitsspeicher des Betreibers von 1Gi auf 2Gi:

oc -n ${PROJECT_CPD_INST_OPERATORS} patch csv <DataStage-CSV-name> --type='json' -p='[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/resources/limits/memory", "value": "2Gi" }]'

Jobs werden in eine Warteschlange gestellt, wenn Compute-Pods nicht gestartet werden können

Wenn die Compute-Pods der Laufzeitinstanz nicht starten, werden alle Jobs auf dem px-runtime-Pod ausgeführt. Ressourcenbeschränkungen führen dazu, dass Aufträge in eine Warteschlange gestellt werden.

Workaround: Beheben Sie alle Probleme, die den Start der Compute-Pods verhindern.

Änderungen am Nachrichtenhandler werden nicht auf einen Joblauf angewendet

Der Nachrichtenhandler wird nach dem Abruf für 3 Minuten zwischengespeichert. Sofortige Änderungen am Nachrichtenhandler haben keine Auswirkungen auf die Jobausführung.

Workaround : Warten Sie einige Minuten, bevor Sie den Auftrag ausführen.

Jobwarteschlange

Wenn Sie einen Auftrag einreichen, wird dieser möglicherweise nicht sofort gestartet. Stattdessen erhält es einen Wartestatus. Auf diese Weise verwaltet das System Ressourcen und priorisiert Aufgaben.

Warum läuft Ihr Job in der Warteschlange?

Grund	Beschreibung
Ressourcenbeschränkungen	Ihr Job wartet darauf, dass die erforderlichen Ressourcen (CPU, GPU, Speicher) verfügbar werden. Das passiert, wenn: Andere Jobs nutzen die gesamte verfügbare Kapazität. Für Ihre Aufgabe sind mehr Ressourcen erforderlich, als derzeit verfügbar sind.
Gleichzeitigkeitsbeschränkungen	Einige Systeme beschränken die Anzahl der Jobs, die gleichzeitig ausgeführt werden können. Ihr Auftrag wird in die Warteschlange gestellt, bis andere Aufträge abgeschlossen sind.
Priorität und Zeitplanung	Aufträge mit niedrigerer Priorität können in die Warteschlange gestellt werden, während Aufträge mit höherer Priorität zuerst ausgeführt werden.
Wartung oder Ausfallzeit	Das System wird möglicherweise gerade gewartet oder aktualisiert, wodurch die verfügbare Kapazität reduziert wird oder die Ausführung von Aufträgen unterbrochen wird.
Warteschlangenrückstand	Hoher Datenverkehr oder eine große Anzahl eingereichter Aufträge können zu einem Rückstau führen. Die Jobs beginnen, wenn die vorherigen Jobs abgeschlossen sind.

Workaround: Der DataStage Workload Manager (WLM) wird mit einer Standardkonfiguration ausgeliefert, die die gleichzeitige Ausführung von 5 Jobs ermöglicht. Wenn Sie über mehr Ressourcen verfügen, sollten Sie pxruntime auf eine größere Instanz skalieren. Weitere Informationen finden Sie unter Anpassen der Hardwarekonfigurationen für DataStage Service-Instanzen mit der Befehlszeile. Nach einer Änderung der Skalierungskonfiguration sollten Sie auch die WLM-Konfigurationsdatei ändern, damit mehr Jobs gleichzeitig ausgeführt werden können. Wenn mehr gleichzeitige Jobs erforderlich sind, sollten Sie die RunJob Einstellungen in der XML-Datei aktualisieren.

Jobwarteschlange

Wenn Sie einen Auftrag einreichen, wird dieser möglicherweise nicht sofort gestartet. Stattdessen erhält es einen Wartestatus. Auf diese Weise verwaltet das System Ressourcen und priorisiert Aufgaben.

Warum läuft Ihr Job in der Warteschlange?

Grund	Beschreibung
Ressourcenbeschränkungen	Ihr Job wartet darauf, dass die erforderlichen Ressourcen (CPU, GPU, Speicher) verfügbar werden. Das passiert, wenn: Andere Jobs nutzen die gesamte verfügbare Kapazität. Für Ihre Aufgabe sind mehr Ressourcen erforderlich, als derzeit verfügbar sind.
Gleichzeitigkeitsbeschränkungen	Einige Systeme beschränken die Anzahl der Jobs, die gleichzeitig ausgeführt werden können. Ihr Auftrag wird in die Warteschlange gestellt, bis andere Aufträge abgeschlossen sind.
Priorität und Zeitplanung	Aufträge mit niedrigerer Priorität können in die Warteschlange gestellt werden, während Aufträge mit höherer Priorität zuerst ausgeführt werden.
Wartung oder Ausfallzeit	Das System wird möglicherweise gerade gewartet oder aktualisiert, wodurch die verfügbare Kapazität reduziert wird oder die Ausführung von Aufträgen unterbrochen wird.
Warteschlangenrückstand	Hoher Datenverkehr oder eine große Anzahl eingereichter Aufträge können zu einem Rückstau führen. Die Jobs beginnen, wenn die vorherigen Jobs abgeschlossen sind.

Lösung: Der DataStage Workload Manager (WLM) wird mit einer Standardkonfiguration ausgeliefert, die die gleichzeitige Ausführung von 5 Jobs ermöglicht. Wenn Sie über mehr Ressourcen verfügen, sollten Sie pxruntime auf eine größere Instanz skalieren. Weitere Informationen finden Sie unter Anpassen der Hardwarekonfigurationen für DataStage Serviceinstanzen mit der BefehlszeileAnpassen der Hardwarekonfigurationen für Serviceinstanzen mit der Befehlszeile DataStage. Nach der Änderung der Skalierungskonfiguration ist es wichtig, die WLM-Konfigurationsdatei zu aktualisieren, um die gleichzeitige Ausführung mehrerer Jobs zu ermöglichen. Wenn Sie also weitere gleichzeitige Jobs ausführen müssen, passen Sie die RunJob Einstellungen in der XML-Datei entsprechend an.

Container-Pods neu starten

Wenn Sie feststellen, dass Compute-Pods unterschiedliches Alter haben, sollten Sie jüngere Container als kürzlich neu gestartet betrachten.

ds-px-default-ibm-datastage-px-compute-0                          1/1     Running     0               169m
ds-px-default-ibm-datastage-px-compute-1                          1/1     Running     0               5h51m
ds-px-default-ibm-datastage-px-compute-2                          1/1     Running     0               2d7h

Workaround: Der Neustart des Containers kann zu einigen Jobfehlern führen. Beispielsweise kann die folgende Fehlermeldung im Auftragsprotokoll angezeigt werden:

##I IIS-DSEE-TLCP-00013 2024-06-19 01:53:18(000) <main_program> SSLConnection(16252672:411,248): Error from SSL read bytesRead=0 ssl_error=5 ssl_error_string= errno=0 errno_string=Success
##E IIS-DSEE-TFPM-00330 2024-06-19 01:53:18(001) <main_program> The Section Leader on node node4 has terminated unexpectedly.
##I IIS-DSEE-TLCP-00013 2024-06-19 01:53:18(002) <main_program> SSLConnection(15598048:411,248): Error from SSL read bytesRead=-1 ssl_error=5 ssl_error_string= errno=104 errno_string=Connection reset by peer
##E IIS-DSEE-TFPM-00330 2024-06-19 01:53:18(003) <main_program> The Section Leader on node node2 has terminated unexpectedly.
##I IIS-DSEE-TLCP-00013 2024-06-19 01:53:18(004) <main_program> SSLConnection(16202192:411,248): Error from SSL read bytesRead=-1 ssl_error=5 ssl_error_string= errno=104 errno_string=Connection reset by peer
##E IIS-DSEE-TFPM-00330 2024-06-19 01:53:18(005) <main_program> The Section Leader on node node3 has terminated unexpectedly.
##W IIS-DSEE-TFPM-00647 2024-06-19 01:53:23(000) <main_program> APT_PMwaitForSectionLeadersCleanup: non-zero status 2 from APT_PMpollUntilZero. If this message persists try increasing the poll timeout seconds by setting APT_PM_CLEANUP_TIMEOUT.
##I IIS-DSEE-TFSR-00115 2024-06-19 01:53:28(000) <main_program> Starting job postRun

Der Container wird aus verschiedenen Gründen neu gestartet, zum Beispiel:

• Es werden zu viele Aufträge gleichzeitig ausgeführt. Der Container verfügt über keinen CPU-Zyklus, um auf OpenShift die Zustandsabfrage zu reagieren. Sie können dies feststellen, indem Sie ausführen oc adm top pods | grep -i datastage und die CPU-Auslastung überprüfen. Wenn die CPU-Auslastung sehr hoch ist, müssen Sie mehr Ressourcen hinzufügen oder die Parallelität in wlm.config.xml.
• Die Ausführung eines großen Auftrags beansprucht den gesamten verfügbaren Speicher. Dies führt dazu, dass der Container in OOMKilled läuft. Sie können dies erkennen, indem Sie die Ausgabe von oc get events | grep -i OOManalysieren.
• Der temporäre Speicher ist aufgebraucht. Standardmäßig sind temporärer Speicher und Rechen-Pods in pxruntime cr auf begrenzt 10GB. Siehe:

[root@solo1 761]# oc get pxruntime -o yaml
apiVersion: v1
items:
- apiVersion: ds.cpd.ibm.com/v1
  kind: PXRuntime
  metadata:
    annotations:
      ansible.sdk.operatorframework.io/verbosity: "3"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"ds.cpd.ibm.com/v1","kind":"PXRuntime","metadata":{"annotations":{"ansible.sdk.operatorframework.io/verbosity":"3"},"name":"ds-px-default","namespace":"ds"},"spec":{"description":"The default DataStage runtime instance","ephemeralStorageLimit":"10Gi","license":{"accept":true},"parameters":{"scaleConfig":"small","storageClass":"nfs-client"},"version":"5.0.0","zenCloudPakInstanceId":"dda5c8d1-9e57-472b-90b9-ce27adbe28ea","zenControlPlaneNamespace":"ds","zenServiceInstanceId":1715711527523198,"zenServiceInstanceNamespace":"ds","zenServiceInstanceOwnerUID":1000331001}}
    creationTimestamp: "2024-05-14T18:32:08Z"
    finalizers:
    - ds.cpd.ibm.com/finalizer
    generation: 50
    name: ds-px-default
    namespace: ds
    resourceVersion: "38308991"
    uid: e9d537c6-5d6b-459a-8ea4-dc7fe4c9b5d5
  spec:
    additional_storage:
    - mount_path: /mnts/pipline
      pvc_name: volumes-pipline-pvc
    - mount_path: /mnts/user-ing-flows
      pvc_name: volumes-user-ing-flows-pvc
    description: The default DataStage runtime instance
    ephemeralStorageLimit: 10Gi

Wenn Sie die Begrenzung für temporären Speicher entfernen oder auf einen höheren Wert ändern möchten, führen Sie oc edit pxruntimeoder aus oc edit sts ds-px-default-ibm-datastage-px-compute. Wenn Sie über weitere DataStage Laufzeitinstanzen verfügen, müssen Sie dieselben Änderungen auch an diesen Instanzen vornehmen.

Migrationsdienste können mit ähnlichen Problemen konfrontiert sein. Um das Problem zu beheben, führen Sie aus oc edit deployment datastage-ibm-datastage-migrationund ändern Sie dann ephemeral-storage: 4Gi , um mehr Platz zu schaffen.

Eine PXRuntime-Instanz, die an einem physischen Standort bereitgestellt wird, kann nicht angezeigt werden

Beim Bereitstellen der Remote-Datenebene auf den Clustern kann es vorkommen, dass die PXRruntime-Instanz, die am physischen Standort bereitgestellt wurde, nicht angezeigt wird. Das passiert, weil die Verbindung geschlossen wird, bevor die Anfrage abgeschlossen ist.

Workaround: Die Timeout-Einstellung für den Load Balancer muss erhöht werden. Weitere Informationen finden Sie unter: Ändern der Timeout-Einstellungen für den Load BalancerÄndern der Timeout-Einstellungen für den Load Balancer.

Jobs bleiben hängen, nicht vorhandene Jobs werden im Status „Startet/Läuft“ angezeigt

Wenn Ihre veralteten Jobs ausgeführt werden, kann es zu Problemen beim Löschen dieser Jobs über die Benutzeroberfläche kommen. Bei den Projekten kann ein ähnliches Problem auftreten, da sie möglicherweise Ressourcen (z. B. Speicher) beanspruchen. Um diese Prozesse zu bereinigen, verwenden Sie einen der folgenden Befehle:

cpdctl asset delete --asset-id ASSET-ID --purge-on-delete=true`

cpdctl dsjob jobrunclean {{--project PROJECT | --project-id PROJID} | {--space SPACE | --space-id SPACEID}} {--name NAME | --id ID} [--run-id RUNID] [--dry-run] [--threads n] [--all-spaces] [--before YYYY-MM-DD:hh:mm:ss]

Hinweis: Mit diesen Befehlen werden alle aktiven Aufträge in einem Projekt gelöscht. Stellen Sie sicher, dass keine neuen Aufträge mehr ausgeführt werden.

Synchronisationsfehler zwischen Pods mit gemountetem NFS Pfad in PXRuntime

Wenn Sie für die Speicherung NFS verwenden, kann es zu Synchronisierungsproblemen kommen, wenn ein Rechen-Pod eine Datei in einen NFS -gemounteten Pfad schreibt und ein anderer Rechen-Pod die Datei sofort liest. Obwohl die Datei im NFS Pfad vorhanden ist, schlagen Lesevorgänge aufgrund der verzögerten Sichtbarkeit über Pods hinweg manchmal fehl.

Workaround: Fügen Sie den actimeo=0 Parameter zur Konfiguration des persistenten Volumes (PV) hinzu.

cat <<EOF |oc apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
  name: sample-nfs-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
  - ReadWriteMany
  mountOptions:
  - actimeo=0
  nfs:
    path: /data/sample-pv    # all worker nodes on the cluster should be allowed 
    server: <NFS server IP>  # to mount the path specified on the NFS server
  persistentVolumeReclaimPolicy: Retain
EOF 

Weitere Informationen finden Sie unter Einrichten eines NFS Mounts.

DataStage Update einschließlich erzwungenem Update wird aufgrund eines festgefahrenen PXRuntime blockiert

Das Upgrade-Problem tritt auf, wenn auf parameters.scaleConfig „benutzerdefiniert” gesetzt ist und gleichzeitig der Skalierungsbereich festgelegt ist. Bei der Unterstützung für benutzerdefinierte Größen erwartet der Operator, wenn auf scaleConfig „benutzerdefiniert” gesetzt ist, dass auch andere Parameter wie parameters.conductorCpus und gesetzt parameters.conductorMemory werden. Wenn die definierten Werte der Parameter niedriger sind als die im scale Abschnitt definierte Anforderung, schlägt der Upgrade-Vorgang fehl, wodurch der hängen px-runtime bleibt.

Workaround : Ändern Sie parameters.scaleConfig in large und entfernen Sie die benutzerdefinierten Ressourcenparameter.

ds-metrics

Kann nicht auf FIPS-toleranten oder FIPS-fähigen ds-metrics Clustern für 5.1.0 Version aktiviert werden

ds-metrics zeigt den folgenden Fehler in den Protokollen an:

java.lang.NoClassDefFoundError: liquibase.snapshot.SnapshotIdService (initialization failure)
liquibase.exception.UnexpectedLiquibaseException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: MD5, provider: SUN,
class: sun.security.provider.NativeMD5)
java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: MD5, provider: SUN, class: sun.security.provider.NativeMD5)
java.security.ProviderException: Error in Native Digest

Workaround: Initialisieren Sie Ihre Datenbank und konfigurieren Sie sie ds-metrics über Umgebungsvariablen. Weitere Informationen zum Aktivieren ds-metricsfinden Sie unter Speichern und Beibehalten von MetrikenSpeichern und Beibehalten von Metriken.

Job_run_log speichert nur Log-Meldungen, die nicht zur INFO-Ebene gehören

Workaround : Setzen Sie die Umgebungsvariable METRICS_SEND_FULL_LOG in der true px-runtime-Instanz auf. Wenn die Variable auf truegesetzt ist, wird das vollständige Job-Ausführungsprotokoll an Metriken gesendet und in der job_run_log Tabelle gespeichert. Um die Umgebungsvariable festzulegen, siehe Speichern und Beibehalten von MetrikenKonfigurieren zusätzlicher Einstellungen für ds-metrics in einer PX-Laufzeitinstanz.

Die Metrikdatenbank kann nach dem Löschen des Schemas „ds-metrics“ nicht vollständig bereinigt werden

Wenn Sie die Datenbank löschen möchten, die ds-metrics mit initialisiert wurde, müssen Sie die Tabellen databasechangelog databasechangeloglock und im public Standard-Schema löschen.

Workaround : Verwenden Sie den folgenden Befehl, um die Metrikdatenbank zu löschen:

drop schema if exists ds_metrics cascade;
drop table if exists public.databasechangelog;
drop table if exists public.databasechangeloglock;

ds-metrics zeigt kurze Fehlermeldungen in den Serviceprotokollen an

Zu Beginn eines Auftragsauslaufs können Fehlermeldungen auftreten, zum Beispiel:

org.hibernate.engine.jdbc.spi.SqlExceptionHelper E logExceptions Batch entry 0 /* insert for
com.ibm.ds.metrics.api.models.JobRun */insert into ds_metrics.job_run (conductor_pid,config_file,controller_id,create_time,duration,instance_id,job_id,last_update_time,partition,queue_name,run_name,run_status,start_time,stop_time,user_status,run_id) values ((NULL),(NULL),(NULL),('2024-10-02 17:54:56.52134+00'),(NULL),('ds-px-default'),('324cac2e-8eac-4452-af75-81ee357fcb82'),('2024-10-02
17:54:56.521442+00'),('2'::int4),('Medium'),('name'),(NULL),(NULL),(NULL),(NULL),('00b84b48-47ea-4a6e-9343-1ed68afb7179')) was aborted: ERROR: duplicate key
value violates unique constraint "job_run_pkey" Detail: Key (run_id)=(00b84b48-47ea-4a6e-9343-1ed68afb7179) already exists. Call getNextException to see other errors in the batch.

Workaround : ds-metrics behandelt die Fehler, die ignoriert werden können.