Wednesday, November 06, 2019

Free Oracle Cloud: 15. The request could not be mapped to any database

This post is the last post of a series of blog posts on the Best and Cheapest Oracle APEX hosting: Free Oracle Cloud.

At some point you might face the following message: "The request could not be mapped to any database":

Oracle is monitoring usage on your Always Free Account and whenever it finds there's no activity for 7 days, it will stop your database automatically. It will preserve the data in the database, but it won't be accessible anymore.

To fix the issue, log in to your Oracle Cloud Account and go to your Autonomous Database:

You will see the database is in a stopped state. Click the Start button:

The state will change to Starting...

And after a minute it becomes available again:

The above behavior is written in the end-user documentation:
Inactivity Monitoring and Database Stoppage
Persistently inactive Always Free Autonomous Databases are detected and handled as follows:
  • After being inactive for 7 days, the database will be stopped automatically, preserving its stored data. Inactivity measurements leading up to 7 days are based on database connections. Successfully making a SQL*Net or HTTPS connection resets these measurements to zero.
  • A database that is automatically or manually stopped and stays inactive for 90 days, cumulative, may be reclaimed and permanently deleted. Inactivity measurements leading up to 90 days are based on the database being inactive or in the stopped state. Starting a stopped database resets these measurements to zero.
    Start an Always Free Autonomous Database by clicking the Start button on the Oracle Cloud Infrastructure console. Start a stopped Always Free Autonomous Database before 90 days to avoid losing access to its data.

But this week there were some people complaining that although they had activity, their database was stopped anyway. I witnessed the same behavior in my account, so I reached out to Oracle and they confirmed their code to identify inactivity, is not properly accounting for APEX/ORDS usage. They are already working on a fix, which they hope to apply very soon. I will update this post when I get confirmation the fix is in the data centers.

Update December 10th: Oracle rolled out a fix end of November to take ORDS and APEX activity in the usage data into account. So whenever you have a REST call or APEX page load, your service should not expire. So far this fixed helped the issue I had in my environment and my instance has not been stopped anymore.


Anonymous said...

Hello Dimitri-
Do you know if it is possible to upgrade to APEX 19.2 on the autonomous transaction database on the always free Oracle cloud? I would really, REALLY like to upgrade this to APEX 19.2...

Dimitri Gielis said...

You can't do it yourself, but I believe that Oracle will foresee an option so you can choose to upgrade.

Anonymous said...

Hi, take a look here:

From the chat I had during the web session:
Q: Will the new APEX version 19.2 be rolled out automatically in an existing ADB?
A: Yes.
Q:And how will I be informed beforehand?
A: There is currently no plan to notify customers about the upcoming APEX 19.2 upgrade. We will look into this for a future release.


Anonymous said...

Hi Dimitri,

Do you know if going to login page and not logging into the apex app would suffice the requirement for resetting the 7day trigger?

Thank you,

Unknown said...

Hello, thanks for sharing so much. well i get this bad request page although the db is green available. i even tried to stop and start but with no success.have you got an idea?

mos said...

Hi Dimitri,

Hope it's not only me but I'm still getting 404 errors. I had to stop/start my ATP 2 times in past 4 days. Is it something we should not be surprised since it's free? I mean Oracle has no SLA for free cloud tier..

i.e. I just got this when I tried to connect my ATP via sqldeveloper.

An error was encountered performing the requested operation:

Listener refused the connection with the following error:
ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

Vendor code 12514

Roy Olsen said...

Thanks for sharing!

I'm still seeing similar problems with my Python/cx_Oracle activity and have made two observations:

* Short lived connections show up in Performance Hub as "Internal" instead of the actual user
* Persistent connections appear to be dismissed by activity detection after a time, possibly the next day

I have both a persistent connection that is inserting rows every few minutes and several new, short lived, connections every minute, and the database still shuts down every few days due to inactivity.

Eslam said...

Dobyou man, inactive for 90 days in a row?