EM13c: Unique Database Service Names on DBaaS

When creating Database through Oracle Enterprise Manager Self Service Portal, we need to enter a “unique” value as database service name. After I set up DBaaS on EM13c, I made several tests until I fix the provision problems (based on my own faults). On each test, I cleaned up failed request, entered a unique service name and submitted a new request. I thought there’s no validation about the service name but then I got an error message complaning “non-unique service name”.

remove_reserved_artifact

As we can see, I tried to enter “murtaza” and it says “murtaza” is not available. I knew that I have already cleaned up failed requests, and there is no service named “murtaza”. Anyway I wanted to be sure and decided to check the existing database services. I noticed that there’s no page showing the existing service names! So I had to enter each database service and check the service name. I had only 3 database services, so it didn’t take so much time.

connection string

The connection string (which we’ll share with the request owner), contains the service name. I couldn’t find any service named “murtaza”. It must be used for a failed request. As I said, I have already cleared and deleted all failed requests, but somehow the service name was stored in the repository. Good thing is, EMCLI verb “dbaas_artifacts” can show and remove these service names which belongs to failed requests:

The “list_reserved_artifacts” parameter lists the reserved names. If there’s on going provision process, its name can also be seen here. If we want to remove any reserved service name, we should use “remove_reserved_artifact” parameter. It seems sometimes, cleaning up and deleting a failed request using the web interface, might not clean all the traces. Also the service names of “rejected” requests are not cleared even we delete the request from the web interface. So I recommended to get familiar with emcli verbs to clean up the unused service names.

Because I removed the reserved service name, I could continue to create a new database service with the same name. To test the validation on service names, I tried to enter an existing service name. Guess what happened? The validation mechanism which checks “reserved service names”, does not check the existing service names!

So I have created several database services with same name. DBaaS created separate databases with unique SIDs for them, but they have same service name. The problem occurs if some of these databases are created on the same host in the database pool, because they will share same listener and register themself as same service name:

Their connection string (which will be shared with the request owner) will be also same, and it can cause serious problems. Oracle surely need to fix the validation mechanism for the service names. Until that time, we should need to find a way to see the existing service names, so as a Cloud Administrator, we can approve the request or ask them to find a new service name.

I connected to the repository database and find a view (SSA_DBAAS$REQUEST_PROPERTIES) which holds the service names used with DBaaS. I joined it with MGMT$TARGET to add host name to the result. The above query also can be useful when we need to remove a database service (on DBaaS) and all we know is its service name.

Please share this post Share on Facebook0Share on Google+0Share on LinkedIn38Share on Reddit0Tweet about this on Twitter

Gokhan Atil is a database architect who has hands-on experience with both RDBMS and noSQL databases (Oracle, PostgreSQL, Microsoft SQL Server, Sybase IQ, MySQL, Cassandra, MongoDB and ElasticSearch), and strong background on software development. He is certified as Oracle Certified Professional (OCP) and is awarded as Oracle ACE (in 2011) and Oracle ACE Director (in 2016) for his continuous contributions to the Oracle users community.

1 Comment

  1. Pingback: Log Buffer #488: A Carnival of the Vanities for DBAs | Official Pythian® Blog – Cloud Data Architect

Leave Comment

Your email address will not be published. Required fields are marked *