Skip to Main Content

 

Auswahl  

Oracle ORDS (bis 21.4.3.x) Fehler und Lösungsvorschläge 

Oracle
APEX
APEX 18.1
15.03.20 (MP)
21.09.23(MP)
Oracle, ORDS 21.x, REST, Fehler, Probleme, Lösungen, Lösungsvorschläge

Passende Schulungen zum Thema

Das heutige Thema beschäftigt mit häufigen ORDS Problemen und Fehlern. Da ich schon mehrere Stunden/Tage auf der Suche nach Fehlern mit der Oracle ORDS Schnittstelle verbracht habe, möchte ich versuchen etwas zu den möglichen Lösungen beizutragen... 

Übersicht: 
0. Debugging einschalten 
1. Datenbankbenutzer prüfen 
2. Problem: Die Bilder-/ CSS-/ Java-Script-Dateien fehlen, oder liegen im falschen Verzeichnis. 
3. Es kommt die Fehlermeldung, dass die Version der Bilder, nicht zur Version von APEX passt. 
4. Die "ords.war"-Datei funktioniert in Verbindung mit Tomcat einfach nicht: 
5. Eine ominöse CSS Datei wird nicht gefunden z.B. 56437564376.css 
6. Mehrere Webserver belegen den gleichen Port 
7. Ein oder mehrere Benutzer sind gesperrt oder das Passwort ist abgelaufen 
8. defaults.xml Datei nicht lesbar/vorhanden 
9. ORDS komplett neu aufsetzen 
10. Fehler 404 The request could not be mapped to any database 
11. 404 Not Found  Die Anforderung konnte keiner Datenbank zugeordnet werden  
12. Fehler 503 Service Unavailable 
13. Internal Server Error 500 

0. Debugging einschalten 

Es hat sich bewährt, bei Problemen rund um APEX, REST oder dem Webserver zuerst mal Debugging einzuschalten: 
Gehen Sie dazu in die Datei defaults.xml (im Ordner den sie bei der ersten Frage der Installation von ords.war angegeben haben), 
dort stehen u.a. evtl folgende Zeilen:

<entry key="db.connectionType">basic</entry>
<entry key="db.hostname">my_db_server</entry>
<entry key="db.port">1521</entry>
<entry key="db.sid">o23c</entry>


Wir ergänzen die folgenden Zeilen, bzw. editieren sie, falls bereits vorhanden.

<entry key="debug.debugger">true</entry> 
<entry key="debug.printDebugToScreen">true</entry> 
<entry key="log.logging">true</entry> 
<entry key="log.maxEntries">500</entry>


Wenn Sie Tests machen möchten, ob die Verbindung funktioniert, können sie auch das Kommandozeilen Tool curl verwenden:

curl http://myserver:8080/ords



1. Datenbankbenutzer prüfen 


Prüfen Sie die Verfügbarkeit der DB-Benutzer mit folgenden SELECT:

SELECT 
    username, lock_date, expiry_date, account_status 
FROM 
    dba_users 
WHERE 
    username IN ( 
        'ANONYMOUS', 
        'APEX_PUBLIC_USER', 
        'APEX_LISTNER', 
        'APEX_REST_PUBLIC_USER', 
        'ORDS_METADATA', 
        'ORDS_PUBLIC_USER' 
    ) 
ORDER BY 1;

Da sollte dann z.B. folgendes als Rückgabe erscheinen: 

USERNAME LOCK_DATE EXPIRY_DATE  ACCOUNT_STATUS 
ANONYMOUS                     28.04.2023 OPEN 
APEX_PUBLIC_USER          30.04.2023  OPEN 
APEX_REST_PUBLIC_USER 30.04.2023 OPEN 
ORDS_METADATA              30.04.202330.04.2023OPEN
ORDS_PUBLIC_USER         30.04.2023 OPEN 



Erklärung: 
Wenn Sie das interne Gateway (Oracle EPG) via Oracle Listener ohne Webserver verwenden, muss der Benutzer ANONYMOUS den Status OPEN besitzen. 
Wenn ein Webserver verwendet wird, kann der Benutzer ANONYMOUS gesperrt sein (LOCKED), jedoch muss der Benutzer APEX_PUBLIC_USER auf OPEN stehen. 
Wenn Sie eine höhere APEX Version besitzen (5.1) werden viele interne Funktionen (auch das Bereitstellen von Bildern, CSS und Javascript z.B. bei den Application Files) via REST Schnittstellen zur Verfügung gestellt. Hier muss auch der Benutzer APEX_REST_PUBLIC_USER entsperrt sein. 
Sollte die Spalte LOCK_DATE bereits ein Datum besitzen, muss der Benutzer entsperrt werden.

ALTER USER <user> ACCOUNT UNLOCK;


Sollte die Spalte EXPIRY_DATE schon in der baldigen Zukunft liegen, sollte die Account-Lebensdauer auch gleich verlängert werden: 
a, Sollte das gleiche Passwort verwendet werden, hier am Beispiel mit Benutzer ANONYMOUS:

select q'!ALTER USER anonymous IDENTIFIED BY VALUES '!'||spare4||q'!' ACCOUNT UNLOCK;!' 
from sys.user$ 
where name='ANONYMOUS';

Führen Sie das zurückgegebene Statement aus, dann wird die Lebensdauer des Accounts verlängert. 
b, wenn Sie das Passwort ändern möchten (Achtung dann muss es auch in einer ORDS XML Datei synchron geändert werden!

ALTER USER ORDS_PUBLIC_USER IDENTIFIED BY owiegutdasniemandmeinpwdweiss;


2. Problem: Die Bilder-/ CSS-/ Java-Script-Dateien fehlen, oder liegen im falschen Verzeichnis. 


Die Fehlermeldung lautet dann z.B. 
There is a problem with your enviroment because the Application Files have not been loaded. 
Prüfen Sie bitte, ob ein Ordner mit Namen "i" im Verzeichnis 
.. tomcat/WebApps/ROOT 
liegt, ansonsten könnte die Seite (weil die CSS-Dateien nicht geladen werden) defekt aussehen. 
Wenn Sie zusätzlich den Apache als ReverseProxy einsetzen, müssen die Dateien im Apache docRoot Verzeichnis liegen (bei uns z.B. in /var/www/html)

3. Es kommt die Fehlermeldung, dass die Version der Bilder, nicht zur Version von APEX passt.

Da muss einfach der Browser Cache geleert werden. Oder Sie haben die Bilder beim Patchen nicht richtig mit den restlichen Dateien zusammenkopiert 
Hinweis: Für Apex 21.2.6 sollten 16.730 Dateien im Bild-Ordner (i) liegen 
In Version 22.2 sind es 15731 Dateien und 1332 Ordner = 17.063 Dateien

4. Die "ords.war"-Datei funktioniert in Verbindung mit Tomcat einfach nicht:

Prüfen Sie die Konsistenz der ords.war Datei mit:

java -jar ords.war validate 
oder 
java -jar ords.war validate --database o21c

Dann sollte folgende Ausgabe erscheinen:

Name des Datenbankservers eingeben [localhost]: 
Listener-Port der Datenbank eingeben [1521]: 
Datenbankservicename eingeben [o21c]: 
Erfordert SYS AS SYSDBA, um das Oracle REST Data Services-Schema zu verifizieren.
Datenbankkennwort für SYS AS SYSDBA eingeben: 
Kennwort bestätigen:
Informationen werden abgerufen.
Retrieving information.
Oracle REST Data Services will be validated. 
Validating Oracle REST Data Services schema version 21.1.0.r3541002 
... Log file written to /root/ords_validate_core_2021-01-16_133103_00877.log 
Completed validating Oracle REST Data Services version 21.1.0.r3541002.  Elapsed time: 00:00:04.798

Sie können natürlich auch noch die dazugehörige Log-Datei analysieren. Da sollte dann z.B. u.a. folgendes zu finden sein:

 

INFO: 08:27:22 Validating objects for Oracle REST Data Services. 
VALIDATION: 08:27:22 Starting validation for schema: ORDS_METADATA 
VALIDATION: 08:27:22 Validating objects 
VALIDATION: 08:27:23 Validating ORDS Public Synonyms 
VALIDATION: 08:27:24 Total objects: 259, invalid objects: 0 
VALIDATION: 08:27:24     72  INDEX 
VALIDATION: 08:27:24      1  JOB 
VALIDATION: 08:27:24     11  PACKAGE 
VALIDATION: 08:27:24     11  PACKAGE BODY 
VALIDATION: 08:27:24     43  PUBLIC SYNONYM 
VALIDATION: 08:27:24      1  SEQUENCE 
VALIDATION: 08:27:24     14  SYNONYM 
VALIDATION: 08:27:24     27  TABLE 
VALIDATION: 08:27:24     26  TRIGGER 
VALIDATION: 08:27:24     19  TYPE 
VALIDATION: 08:27:24      6  TYPE BODY 
VALIDATION: 08:27:24     28  VIEW 
VALIDATION: 08:27:24 Validation completed. 
INFO: 08:27:24 Completed validating objects for Oracle REST Data Services.

Ein Problem, was mir vier Wochen Suche beschert hat. Wir hatten bei der Installation von ORDS immer das Problem, dass sich die Installation an einer Stelle aufgehängt hatte. Sie hing ca. 15 min und stüzte dann ab mit " IO Error: Connection reset by Peer". 
Das Problem war, dass Java auf unserem System (CentOS 7) mit "/dev/random" nicht genügend viele Zufallszahlen berechnen konnte und stattdessen "/dev/urandom" nehmen musste.

Dazu müssen Sie bei der Installation folgendes zuätzlich angeben:

java -Djava.security.egd=file:///dev/urandom -jar ords.war

Allerdings kann man auch dem Pool der Zufallszahlen von "/dev/random" etwas mehr Entropie verleihen und daher weiterhin "/dev/random" nutzen. Dazu installiert man sich ein entsprechendes Tool:

yum install haveged 
systemctl enable haveged; systemctl start haveged;

 

5. Eine ominöse CSS Datei wird nicht gefunden z.B. 56437564376.css

Hier war eine fehlerhafte ords Installation schuld, es fehlte die Datei apex_rt.xml

Prüfen Sie nach der Installation, ob die folgenden Dateien im angegebenen Config Verzeichnis liegen:

  • apex_al.xml  <= Diese Datei wird vom APEX_LISTENER benötigt !!
  • apex_pu.xml <= Diese Datei wird vom ORDS_PUBLIC_USER benötigt !!
  • apex_rt.xml  <= Diese wird vom APEX_REST_PUBLIC_USER benötigt !!
  • apex.xml       <= Diese Datei wird vom APEX_PUBLIC_USER benötigt !!

Die Dateien sehen wie folgt aus (und können auch manuell erstellt werden):

apex.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@05939D2C32A74181B5BCBA375C0794A111</entry>
<entry key="db.username">APEX_PUBLIC_USER</entry>
</properties>


apex_al.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@05B2B32CE300417F3AE4BAD1112826CB84E</entry>
<entry key="db.username">APEX_LISTENER</entry>
</properties>


apex_rt.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@0577928598D4BAB7423441C0D8DF0855F</entry>
<entry key="db.username">APEX_REST_PUBLIC_USER</entry>
</properties>


apex_pu.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@05651DD1203D235C56A0585BC871A336A2</entry>
<entry key="db.username">ORDS_PUBLIC_USER</entry>
</properties>
Fehlerhafte / fehlende Dateien weden auch in der log Datei catalina.out angezeigt:
Wenn Sie übrigens das Passwort für einen dieser 4 Bebnutzer geändert haben, sollten Sie das hier in den Dateien auch durchführen. Geben Sie dazu das Passwort im KLARTEXT mit einem führenden ! in die Datei ein.
Also wenn ihr Passwort lautet: Suchmich2023## schreiben Sie in die Datei:
<entry key="db.password">!Suchmich2023##</entry>
<entry key="db.username">APEX_REST_PUBLIC_USER</entry>
 
Wenn Sie dann den TomCat Webserver durchbooten, sollte das Passwort wieder verschlüsselt mit einem führenden @ in der Datei stehen
systemctl stop tomcat && systemctl start tomcat
 
Sollte die Verschlüsselung nicht funktioniert haben, prüfen Sie doch mal bitte ob es das richtige Verzeichnis war in dem Sie die Datei editiert haben und ob TomCat schreibrechte auf dem Ordner/ den Dateien besitzt !
 
Bei uns stand wegen der fehlenden apex_rt.xml Datei im Logfile vom Tomcat (Datei: catalina.out):
Caused by: oracle.dbtools.url.mapping.TargetNotAvailableException: The connection pool named: apex_rt does not exist 
        at oracle.dbtools.url.mapping.db.PoolInjector.inject(PoolInjector.java:60)


Eine CSS Datei des Theme Rollers konnte auf einem Server teilweise nicht mehr gefunden werden. Teilweise ist immer spannend ... 
Ein Blick in die catalina.out brachte etwas Licht ins Dunkel: Einige ORDS_METADATA Views waren invalid- Bei genauerer Betrachtung der Views, stellte sich heraus, dass die dazu passenden Tabellen gar nicht (mehr) da waren. 

Nur wo werden diese angelegt? Nach einiger Suche habe ich beim Auspacken des ords.war Files die Datei ords_database.objects.sql im Ordner scripts/install/core gefunden. 
Nachdem das Skript nochmal installiert wurde (bitte im Schema ORDS_METADATA) lief wieder alles perfekt. 
Sicherheitshalber kann man natürlich einen Zusatzcheck durchführen (hier mir ORDS Version 19.4 (Stand 15.03.2020))

SELECT 
    object_type,    COUNT(valid),    COUNT(invalid) 
FROM 
    ( 
        SELECT object_type, 
            CASE 
                WHEN status = 'VALID' THEN   1 
            END AS valid, 
            CASE 
                WHEN status <> 'VALID' THEN 1 
            END AS invalid 
        FROM 
            dba_objects 
        WHERE 
            owner = 'ORDS_METADATA' 
    ) 
GROUP BY 
    object_type 
ORDER BY    1;


Das Ergebnis sollte in 19.4 (für 21.2 in Klammern) dann so aussehen:

OBJECT_TYPE VALID   INVALID 
INDEX 75 (86) 0 
JOB 1 (1) 0 
LOB 3 (3) 0 
PACKAGE 12 (20)0 
PACKAGE BODY 12 (19)0 
PROCEDURE 1 (1)0 
SEQUENCE1 (1)0 
SYNONYM 14 0 
TABLE 27 (30)0 
TRIGGER 27 (30)0 
TYPE 20 (20)0 
TYPE BODY 6 (6)0 
VIEW28 (34)0


6. Mehrere Webserver belegen den gleichen Port 


Prüfen Sie, ob das Oracle EPG evtl. den gleichen Port, wie Ihr Webserver belegt:

SELECT dbms_xdb.gethttport FROM dual;

Falls es der gleiche Port wie im Webserver ist, können Sie ihn wechseln:

EXEC dbms_xdb.sethttpport(0); -- Ausschalten des Datenbank Ports 
EXEC dbms_xdb.sethttpport(9090);  -- Anderer Port

oder unter Linux auf OS Ebene:

netstat -tulpn | grep 8080



7. Ein oder mehrere Benutzer sind gesperrt oder das Passwort ist falsch bzw. abgelaufen: 


Benutzer APEX_PUBLIC_USER 
Webserver Fehler: 503 Service Unavailable 
Wenn Debugging eingeschalten ist, dann auch noch: 
Der Verbindungspool namens |apex|rt| ist aufgrund der folgenden Fehler nicht korrekt konfiguriert: ORA-28000: Account ist gesperrt. 
Witzigerweise kann die Fehlermeldung auch erscheinen, wenn das Passwort falsch ist! 
Wenn Debugging ausgeschalten ist, bekommen Sie den Fehlertext: 
Benutzer oder Kennwort für den Verbindungspool namens |apex|| ist ungültig oder abgelaufen, oder der Account wurde gesperrt 
Lösung:

ALTER USER apex_public_user [IDENTIFIED BY meinpasswort] ACCOUNT UNLOCK;

Wenn Sie das Passwort auf dem Oracle Server geändert haben, muss es natürlich auch auf dem Oracle Client ( dem Webserver) geändert werden. 
Dass Passwort steht in Datei mit Namen apex.xml (im Ordner den sie bei der ersten Frage der Installation von ords.war angegeben haben) 
In der Datei sind u.a. folgende Zeilen:

<entry key="db.password">@0574B6939D4387C95AD95DA10B99690D65</entry> 
<entry key="db.username">APEX_PUBLIC_USER</entry>


Setzen Sie das geänderte Passwort unverschlüsselt mit vorangestellten ! in die Datei ein (nur bis ords 21.3.4 !!):

<entry key="db.password">!meinpasswort</entry>


Das Passwort wird beim Neustart des Webservers automatisch verschlüsselt. 

Benutzer: APEX_PUBLIC_REST_USER 
Symptome: Static und Workspace Files werden nicht mehr angezeigt 
Webserver Fehler: 503 Service Unavailable 

Wenn Debugging eingeschalten ist, dann auch noch : 
Der Verbindungspool namens |apex|rt| ist aufgrund der folgenden Fehler nicht korrekt konfiguriert: ORA-28000: Account ist gesperrt. 
Witzigerweise kann die Fehlermeldung auch erscheinen, wenn das Passwort falsch ist! 
Wenn Debugging ausgeschalten ist, bekommen Sie den Fehlertext: 
Benutzer oder Kennwort für den Verbindungspool namens |apex|| ist ungültig oder abgelaufen, oder der Account wurde gesperrt 
Lösung:

ALTER USER apex_public_user [IDENTIFIED BY meinpasswort] ACCOUNT UNLOCK;


Dass Passwort steht in Datei mit Namen apex_rt.xml (auch hier im Ordner den sie bei der ersten Frage der Installation von ords.war angegeben haben) 
In der Datei sind u.a. folgende Zeilen:

<entry key="db.password">@0574B6939D4387C95AD95DA10B99690D65</entry> 
<entry key="db.username">APEX_REST_PUBLIC_USER</entry>


Setzen Sie das geänderte Passwort unverschlüsselt mit vorangestellten ! in die Datei ein:

<entry key="db.password">!meinpasswort</entry>


Das Passwort wird beim Neustart des Webservers automatisch verschlüsselt. 

8. defaults.xml Datei nicht lesbar/vorhanden 


Prüfen Sie, ob die Konfigdatei defaults.xml lesbar und für den Webserver (z.B. TomCat) lesbar und auch im richtigen Ordner zur Verfügung steht. 
Fehler: 404 Not Found 
Die Anforderung konnte keiner Datenbank zugeordnet werden. Stellen Sie sicher, dass die Anforderungs-URL richtig ist und dass Zuordnungen zwischen URL und Datenbank korrekt konfiguriert wurden. 

Lösung: 
Stellen Sie sicher, das der Webserver (z.B. TomCat) auf die Datei zugreifen kann. Einfacher Trick: Benennen Sie die Datei um und starten 
Sie den Webserver durch. Er legt selbst eine neue Datei an. Falls nicht, gibt es evtl im Verzeichnis ein Rechteproblem. 

Wenn Sie nicht wissen, in welchen Verzeichnis die Datei liegt: 
im Webserver liegt im ords/WEB-INF Ordner eine Datei mit Namen web.xml. Dort steht u.a.

<param-name>config.dir</param-name> 
<!-- Enter the location where configuration settings should be stored --> 
<param-value>c:\oracle\ords_conf</param-value>


Bei uns hatte sich ein weiterer Fehler in einem Server eingeschlichen: 
Die SQL*Plus Datei pupbld.sql Datei wurde bei der Installation einer neuen Datenbank nicht installiert. Das hatte zur Folge, dass bei jeder Anmeldung eines Benutzers an der Datenbank eine Fehlermeldung:

Kennwort eingeben: 
ERROR: 
ORA-00942: Tabelle oder View nicht vorhanden 


Fehler bei Zugriff auf PRODUCT_USER_PROFILE 
Warnung:  Daten zu der Tabelle Product User Profile sind nicht geladen 
PUPBLD.SQL sollte als SYSTEM gestartet werden 
Letzte erfolgreiche Anmeldezeit: Mi Mrz 25 2020 14:02:32 +01:00 

Verbunden mit: 
Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production 
Version 18.4.0.0.0


Nachdem wir die Datei (@?/sqlplus/admin/pupbld.sql) installiert hatten, funktionierte das Ganze nach einem Neustart des Webservers wieder. 
Sie sollten bei 404 Problemen generell die Hauptverdächtigen Benutzer ( APEX_PUBLIC_USER, ORDS_PUBLIC_USER und APEX_REST_PUBLIC_USER) mal manuell an die Datenbank anmelden. Wenn es da Probleme gibt, sollte diese zuerst gelöst werden! 
 

9. ORDS komplett neu aufsetzen: 


a, Benutzer löschen

SQL> DROP USER apex_listener CASCADE; 
SQL> DROP USER apex_rest_public_user CASCADE;
 

b, Webserver beenden

systemctl stop tomcat


b, ORDS deinstallieren:

java -jar ords.war uninstall

c, ords Configurations Verzeichnis finden und löschen 
Anzeige mittels:

java -jar ords.war configdir

Rückgabe: 
Mar 17, 2020 9:33:17 AM 
INFO: The config.dir value is /u01/software/oracle/ords/config 
d, Löschen des Verzeichnis:

rm -rf /u01/software/oracle/ords/config

Es sollte auch der ords.war und das Verzeichnis ords im Webserver (z.B. in /opt/tomcat/latest/webapps) gelöscht werden 
e, APEX_REST_CONFIG Skript als SYS neu starten

SQL>@apex_rest_config.sql

f, den Oracle ORDS neu konfigurieren: 
Hinweis: Packen Sie die datei ords.war immer neu aus dem Zip-Verzeichnis aus. Es könnten von der letzten Konfiguration sich fehler eingeschlichen haben.

java -jar ords.war
g, ords.war in das Webserver Verzeichnis verschieben
mv ords.war /opt/tomcat/webaps

h, Webserver (z.B. TomCat) wieder starten

systemctl start tomcat

und testen ob es nun funktioniert! 
10.The request could not be mapped to any database 

Der Fehler lautet: URLMappingNotFoundException [statusCode=404, reasons=[The request could not be mapped to any database. Check the request URL is correct] 
Hier war der Rest-Service ausgeschalten. Sie können ihn einschalten mittels:

EXEC apex_instance_admin.set_parameter('RESTFUL_SERVICES_ENABLED','Y'); 
 
 

Der Fehler tritt derzeit in Apex 20.1 bis 22.2 auf. 
Lösung laut Metalink Doc: ID 2685135.1: 

Schalten Sie die Option Friendly URL aus (Shared Components / Application Defintion Attributes) 

[Update vom 6.6.2021) Fehler 404 bei Rest Service 
Diese Mal war das Kennwort des ORDS_PUBLIC_USER abgelaufen.

select username,account_status,lock_date,expiry_date 
from dba_users u 
where username in ('APEX_PUBLIC_USER','ORDS_PUBLIC_USER','APEX_LISTENER');
USERNAME          ACCOUNT_STATUS  LOCK_DATE  EXPIRY_DATE          
----------------- --------------- ---------- -------------------- 
APEX_LISTENER     OPEN                       10.11.2022 11:40:31 
APEX_PUBLIC_USER  OPEN                       10.11.2022 12:12:53 
ORDS_PUBLIC_USER  OPEN                       10.11.2022 12:13:07

12. Fehler 503 Service Unavailable 


Der Datenbankbenutzer für den Verbindungspool |apex|pu| kann das Schema SCOTT nicht als Proxy verwenden. 
Möglicherweise ist eine Einschränkung der maximalen Anzahl an Datenbanksessions konfiguriert, oder ein Autorisierungsfehler liegt vor. 

Die Lösung war bei uns:

alter user scott grant connect through ords_public_user;

Ein ähnlicher Fehler war 
13. 500 Internal Server Error

Ein unerwarteter Fehler mit der folgenden Fehlermeldung ist aufgetreten: 
InternalServerException [statusCode=500, logLevel=SEVERE, reasons=[]] 

Caused by: java.sql.SQLException: ORA-00604: Fehler auf rekursiver SQL-Ebene 1 
ORA-01031: Nicht ausreichende Berechtigungen 
... 
Caused by: Error : 604, Position : 0, Sql = 
select nvl(h.items_per_page,m.items_per_page) items_per_page, t.etag_type, t.etag_query, h.source_type, m.origins_allowed, cursor
(select p.name, p.bind_variable_name, p.source_type,p.access_method, p.param_type from user_ords_parameters p where p.handler_id = h.id) 
parameters, h.source from user_ords_modules m, user_ords_templates t, user_ords_handlers h where m.status = 'PUBLISHED' and t.id = h.template_id and m.id = t


Hier mussten READ Rechte von allen ORDS Objekten an den Ziel-Benutzer vergeben werden. 

Neuer Fehler: 
500 Internal Server Error mit Fehlertext NULL 

Da haben wir etwas länger gesucht. Schuld war die falsche Java Version. OpenJDK Version 11 oder 17 lief bei uns nicht, wir mussten das Oracle JDK installieren! 
Prüfen Sie immer auch, ob TomCat die Rechte hat das Config File zu lesen. Eine Fehlermeldung in der Form: Konnte Config datei nicht finden oder hatte keine Rechte darauf gibt es nicht. 
Stattdessen meckert der Ords, dass er keine Verbindung zur Datenbank hinbekommt! 

Neuer Fehler 
500 Internal Server Error (im Logfile steht dann noch ORA-1005 Null password given) 
Unter Linux und Ords < 22.x darf der Parameter -Dconfig nicht verwendet werden! 
Datei /etc/systemd/system/tomcat.service:

Description=Tomcat  
After=syslog.target network.target 

[Service] 
Type=forking 
User=tomcat 
Group=tomcat 

Environment=JAVA_HOME=/usr 
Environment='JAVA_OPTS=-Djava.awt.headless=true' 
#Achtung bis Ords 21.4.3 darf der Parameter hier nicht stehen, aber ab Ords 22.x muss er hier stehen ! 
#Environment='JAVA_OPTS=-Dconfig.url=/opt/oracle/ords' 


Environment=CATALINA_HOME=/opt/tomcat/latest 
Environment=CATALINA_BASE=/opt/tomcat/latest 
Environment=CATALINA_PID=/opt/tomcat/tomcat/temp/tomcat.pid 

ExecStart=/opt/tomcat/latest/bin/catalina.sh start 
ExecStop=/opt/tomcat/latest/bin/catalina.sh stop 

[Install] 
WantedBy=multi-user.target



Ich hoffe ich konnte dem einen oder der anderen ein paar Stunden an Suche nach den Webserver Fehlern (404) mit diesen Tipps ersparen. 

Besuchen Sie uns doch einmal in einer unserer Schulungen in München-Unterhaching. Falls Sie nicht reisen können oder dürfen, 
können Sie bei unseren Schulungen auch vom Home-Office oder Ihrem Arbeitsplatz per Streaming teilnehmen. 
Bei weiteren Fragen stehen wir Ihnen gerne zur verfügung. Bleiben Sie BITTE gesund!