Recap of the Basic Docker Workflow

Let’s assume you’ve just switched your machine on and you want to do some work with your containerized Oracle Database instance and SQL Developer. The following is the set of steps required along with the necessary commands.

Check the running Docker containers and look specifically for the Oracle container using this command:

docker
container
ls
–
a

Copy the resulting container ID and run the following command, substituting your own container ID:

docker
start
380195
f59d0d

After a minute or so, rerun the container command to check the container status:

docker
container
ls

–
a

Then, if all is well, the STATUS value should change to indicate the container is healthy. To shut down the container, just run the same command but use stop in place of start, so it looks like this:

docker
 
stop
 
380195
f59d0d

As always, remember to use the container ID specific to your own setup. The preceding code is, of course, the value from my system.

Oracle Database SID Versus Service Name

During the installation procedure, you might have wondered about the difference in Figure 2-7 between SID and Service name.

The SID is a unique name representing the installed Oracle Database instance, i.e., the Oracle process running on the machine. Documentation suggests that Oracle considers the database to be the underlying files.

The Service name is different from the SID in that the former represents an alias to one or more Oracle instances. The main purpose for having two mechanisms is that if you are running a cluster of Oracle Databases, then the client can request a connection to a given service name without having to specify the exact underlying instance.

The service option also facilitates flexibility in database administration procedures. For example, the number of instances in a given clustered service can be increased (or decreased) without requiring the client to change any local configuration settings. That can be very convenient if the client in question is built using a high-level language such as Java or C#. The database configuration of such clients might be embedded in the application source code. This means that database configuration modifications might in turn necessitate an application rebuild and redeployment procedure.

A more flexible setup would involve the service name pointing to the cluster as a whole. This way, dependent client applications can retain their more general configuration while still allowing the database administration some degree of flexibility.

These types of issues typically only become relevant for somewhat larger installations with multiple Oracle Databases. The use of the tnsnames.ora file and other options comes into play in these more complex environments.

In the next section, you’ll see SQL Developer being used.