Friday, March 27, 2026

AWS DMS Task error Command failed to load data with exit error code 0 and exitwhy 1 when source Oracle and target PostgreSQL databases


DMS issue resolved: 

=================


DMS task Endpoint setting for data type error : by default DMS migration number data type with precision , to avoid 

  This error we need to setup endpoint with below extra connection (source : Oracle Database target: Aurora PostgreSQL) 


In cloudWatch log, you will see like this - 


[TARGET_LOAD     ]E:  Command failed to load data with exit error code 0 and exitwhy 1. Please check target database logs for more information.       



Cause of this issue-  mismatch in data types or precision between your source and target databases. When columns defined as numeric data types without specified precision or scale. In this senerio DMS won’t able migrate without below extra endpoint setting. 




For source endpoint:  Oracle SE 2 

===============

   DMS —> Migrate or replicate. —> Endpoints
            select   Use endpoint connection attributes  then 

  Endpoint setting :   Extra connection attributes 

              NumberDatatypeScale=-2;


Pasted Graphic.png


For Target endpoint: Aurora PostgreSQL (Engine version 17.4) 

===============

   DMS —> Migrate or replicate. —> Endpoints

       select   Use endpoint connection attributes  then 

     Endpoint setting :   Extra connection attributes 

       

       MapUnboundedNumericAsString=true;


Pasted Graphic 1.png



Addition info for DMS task setting for this migration:  

 Because DMS by default migrate all names as Upper case for PostgreSQL or Mysql so, if you need lower-case then set up this rules 


Schema Name: HALIM


Table mappings

==============

Selection rules

where schema name is like 'HALIM' and table name is like '%', include


Transformation rules

where schema name is like 'HALIM' , convert-lowercase          # for schema 

where schema name is like 'HALIM' and table name is like '%' , convert-lowercase.  # For Tables 

where schema name is like 'HALIM' and table name is like '%' and column name is like '%' , convert-lowercase. # For Columns 



Tuesday, September 2, 2025

RAG: Retrieval Augmented Generation approaches

 

RAG:  Retrieval-Augmented Generation approaches. This is for my personal reference. 







Thursday, October 12, 2023

403 forbidden error in oracle apex 20.2.1 does not support Cross Origin Sharing request

Can not access to oracle apex. faced below issue when tried to login from ORDS on development mode. 

 


403 Forbidden

The request cannot be processed because this resource does not support Cross Origin Sharing requests, or the request Origin is not authorized to access this resource. If ords is being reverse proxied, ensure the front end server is propagating the host name, for mod_proxy ensure ProxyPreserveHost oi set ON.

 

Solution: 

Application ORDS is configured to access only with https://, so we have added below parameter in ORDS defaults.xml (ords/conf/ords/defaults.xml)  configuration file and restarting ORDS. it resolved the issue.  

 

<entry key="security.forceHTTPS">true</entry>

 

Application configured with ORDS in Weblogic server. 

 

 

Just FYI- 

From ORDS 20.4 onwards we can use this below parameter for cross origin sharing request

 

 

<entry key="security.externalSessionTrustedOrigins">http://example.com,https://example.com:8443</entry>

 



For more info- 

Cross-Origin Resource Sharing Feature

 

https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/22.1/orddg/migrating-mod_plsql-ords.html#GUID-ACAAB207-8475-403E-A757-304D7E76B2EF

Wednesday, February 1, 2023

403 Forbidden Access to the procedure named: apex is denied or wwv_flow.accept is denied

403 Forbidden Access to the procedure named: apex is denied. 

Access to the procedure named: wwv_flow.accept is denied. 

Failed to load resource the server responded wwv_flow.accept

Failed to load resource: the server responded with a status of 403 (Forbidden) 
 

Background:

Oracle APEX version 20.2 (probably same for 19.2 onwards) and ORDS 17.4 and later

Apex (version 20.2) application was running fine from last 1.5 years without any issues. Before 2 days of the incident, deployed a new apex application on the same APEX instance, it is running on ORDS (18.1) which is deployed in Weblogic application server.  

Suddenly, faced above issues when tried to login in URL:port/ORDS,  user also faced Error: Forbidden. When tried to login. so totally struck everything. No one know what happened! Nothing changed!

 

Found the Cause:

After a marathon research, we found that there was a security feature in APEX (on ORDS) kicked off - "security.requestValidationFunction">wwv_flow_epg_include_modules.authorize (This is reside in file defaults.xml  on ORDS/conf location in apps server ).  Learned that, this property and DB function work as whitelisting entries. Means it activates the whitelist of callable procedures which ships with Oracle Application Express and prohibits calls to other procedures.

As per Oracle, when a database pool is configured to use the APEX_PUBLIC_USER, ORDS automatically sets or checks the value of the property security.requestValidationFunction on xml config file (ords/conf/ords/defaults.xml)    as below.

<entry key="security.requestValidationFunction">wwv_flow_epg_include_modules.authorize</entry>

<entry key="security.validationFunctionType">plsql</entry>

 

We found that database package wwv_flow_epg_include_modules  (in schema apex_200200) and function authorize is empty. So when validating this property nothing got passed to ORDS from APEX instance.  

 

Solution:  

For temporary solution,

       1) we made this property empty with this below command.

u01/ords$ java -jar ords.war set-property security.requestValidationFunction ""

2)        2) and then bounce or stop/start the ORDS service deployment in Weblogic server by login in Admin console.

OR

You may remove these two lines from this above default.xml files 

<entry key="security.requestValidationFunction">wwv_flow_epg_include_modules.authorize</entry>

<entry key="security.validationFunctionType">plsql</entry>

 Then bounce the ORDS.

 

For details:  An Oracle REST Data Services deployment configuration contains several security related parameters. In a configuration for Oracle Application Express, Oracle recommends to set the parameter security.requestValidationFunction to wwv_flow_epg_include_modules.authorize. This activates the white list of callable procedures which ships with Oracle Application Express and prohibits calls to other procedures. This can be extended using the validation functions shipped with Oracle Application Express. https://docs.oracle.com/en/database/oracle/application-express/19.2/htmdb/web-listener-security.html

 

 https://joelkallman.blogspot.com/2016/07/securing-application-express-when-using_24.html

https://www.promatis.at/en/2022/07/13/lessons-learned-while-upgrading-apex-and-ords-to-22-1/

https://oracle-base.com/articles/misc/oracle-rest-data-services-ords-database-authentication

https://forums.oracle.com/ords/apexds/post/403-forbidden-access-to-the-procedure-named-wwv-flow-accept-5111

 

 

Wednesday, October 5, 2022

ORA-01017: invalid username/password; logon denied in oracle 12c Dataguard DG broker Suddenly

 It's been long time everything was working fine with oracle DG broker (dgmgrl> ).  Suddenly we faced this error in DG broker while trying to valid network configuration before a SWITCHOVER operation, even though no one change any credentials. 


After sometime, we realized that we were connected to DG broker as SYSDG user (normally connect with SYS). and then found that, the SYSDG user's credential are not same in both PRIMARY and STANDBY password file. that's why it is not able to connect. Here is the query to check this in both environments -   

SQL> select * from v$pwfile_users;

Then logout and connect back with SYS user, everything worked perfectly.

 dgmgrl> connect sys 

So solution is- 1) Either you need to change SYSDG user's credentials in both database same (since remote_login_passwordfile is set to EXCLUSIVE) . so it will saved and match in Password file.

2) OR login with a different super user (like SYS) who's credentials are same for both databases. 


For details you may read- ora-01017