Tag: 23c

  • ORDS install considerations: choosing the correct host, port, service name, and pluggable database when the database is in a podman container

    The other day, I wrote about how I had to start from scratch on my podman containers 😢. I’m now at the step where I need to reinstall ORDS in these two new database containers (21c and 23c). And since I’m doing this install yet again, I figured I would point out some things I’ve learned while doing this with podman containers. This post isn’t meant to be all-inclusive; I’m simply highlighting the areas that gave me the most trouble.

    Lettuce begin

    My assumptions are that you’ve downloaded the ORDS zip file or from a Yum repository (how-to article here). You’ve also set the ORDS configuration folder path and the ORDS product folder path (both are necessary steps for ORDS pre-installation). You can read up on that step here.

    The ORDS Interactive Installer

    Here, I’m installing ORDS with the Interactive Installer.

    ords-interactive-installer-screenshot-chris-hoina-senior-product-manager-oracle-rest-data-services-database-tools
    Do this with the ords install command

    The fine print

    NOTE: For a vanilla installation, most of the default prompts are correct. But for working with a podman container, I do not believe all the default settings will work (at least, this has been my experience). 

    The ORDS Interactive Installer will prompt you with the default settings, where appropriate. You’ll notice the Choose [value]: convention. These settings are okay to use in many steps, but if you mindlessly follow them in specific steps, you might end up with the incorrect ORDS installation for your particular use case.

    Select the type of installation

    For instance, in the “Enter a number to select the type of installation” step, I’m prompted with the [1] option. For me, that is incorrect; I need to choose [2].

    type-of-installation-ords-interactive-installer-chris-hoina-senior-product-manager-oracle-rest-data-services-database-tools
    Option [2] I choose you!

    Database pool to update or create

    Things can get tricky here, too. In this step, I WILL choose option [1], but in the next step, I WILL NOT select the default settings (read on about host names, ports, and service names).

    basic-connection-ords-interactive-installer-chris-hoina-senior-product-manager-oracle-rest-data-services-database-tools
    This default string is simply an example; with podman you may not be using 1521 as the port.

    Selecting the database connection type

    And here’s why I won’t use the default settings. It’s because I have mapped the ports to/from my podman containers like this:

    podman-container-configurations-chris-hoina-senior-product-manager-oracle-rest-data-services-database-tools
    If you don’t map a port, podman will pick one for you!

    My 21entdb container is set up such that my computer sends and receives podman container traffic on port 41465. Meanwhile, my podman container is set up so that it will send and receive data on port 1521 (which is the default port for Oracle’s TNS Listener).

    Another way of looking at this is to imagine port 41465 is sort of spoofing port 1521. Ehh..maybe it’s better to think of it like a pass-through, a proxy, a go-between if you will…but more on this in a second.

    Demystifying the connection string

    Here, I’ll test both ports, the Container (ORCLCDB) and Pluggable (ORCLPDB1) databases, with various connection strings.

    QUESTION: How do I even know my options are ORCLCDB or ORCLPDB1? Well, I learned about them in the container registry documentation.

    Using port 1521

    First, let’s see what happens when I try to log into my database with SQLcl, using 1521 as the port:

    Nothing! Initially, for me, this made no sense! And that’s because, in my mind 1521 is the port that you would expect to connect with! This whole network business was confounding! That was until I realized that you have to use your computer’s port to connect to the podman container (which is listening on port 1521).

    Using the port podman assigned to you

    Ah-ha! Now, if you make that slight change to the ports, you can connect to your Container (ORCLCDB) and Pluggable (ORCLPDB1) databases.

    Does this help? Do you have a better understanding of why your port might not be 1521?

    Host, port, and service names

    You can probably keep the localhost default selection. When it comes to the listen port selection, I must choose 41465 and not 1521. And for the database service name, you could choose ORCLCDB (i.e. Oracle Container Database), but we recommend installing ORDS into a Pluggable Database (read up on this in our ORDS Best Practices). Here you see me do just that; ORCLPDB1 is the ORDS default, but I wanted to highlight why this is the default.

    host-port-service-name-ords-interactive-installer-chris-hoina-senior-product-manager-oracle-rest-data-services-database-tools

    Provide database user

    In this step, I’m supplying the username and password of a user with the necessary privileges to log into the database to complete the ORDS installation. In this case, unsurprisingly, it is the SYS user (the default). We also have an ORDS Installer Privileges script you can execute if you’d rather grant another user privileges to install, upgrade, repair, and uninstall ORDS. You can find more details on that script here.

    A great example showing how the JDBC driver is using the host, port, and service name values you provided.

    Enabling features

    This isn’t the final ORDS install step; this is just the last step I wanted to point out. The default here is also [1]. And I think you should keep it like that, here’s why. When you select [1], you’ll also give users access to Database Actions – the Graphical User Interface (which shares much in common with the SQL Developer desktop client). Once you start using Database Actions, it’s hard to stop.

    enable-additional-features-ords-interactive-installer-chris-hoina-senior-product-manager-oracle-rest-data-services-database-tools
    Don’t ask any questions; select option [1].
    NOTE: You'll also be enabling the REST-enabled SQL service (as well as the Database API). I recently wrote about the ORDS REST-Enabled SQL Service; it's very cool, and you should check out that article here.  

    The end

    Aaanndd, that’s my time. They’re flashing the lights, so I have to get off the stage 🙁. Hopefully, this note will be helpful when you create some containers from images on the Oracle Container Registry. And if you think you might like to tinker with ORDS, bookmark this post so you can refer to it later!

    Follow

    And don’t forget to follow, like, subscribe, share, taunt, troll, or stalk me!

  • Podman container is unhealthy with Oracle database images

    Podman container is unhealthy with Oracle database images

    Problem Description

    You’re working with podman containers (maybe like me – the ones from the Oracle Container Registry), and when you execute the podman ps command, you see something like this in the standard output:

    podman ps unhealthy with new database chris hoina senior product manager ords database tools oracle
    A container status of unhealthy

    In this case, I already had another container with an Oracle 21c database; that one was healthy. I previously wrote up a tutorial on how I did that here. But when I attempted to create another container with the Oracle 23c Free database, this is where things went sideways. This new container would constantly display an unhealthy status 😭 (not working).

    Why am I even doing this? Well, we have a bunch of cool new ORDS features that take advantage of the 23c database, and we want to start showcasing that more. It would be nice to be able to show this in containers.

    Digging deeper

    Issue the podman logs (not log, duh) command for this particular container. Very few details are revealed (technically, it does reveal relevant information, I just need to figure out what I’m looking at here).

    podman logs command chris hoina senior product manager ords database tools oracle

    That ORA-12752 error message is…an error message.

    ora-12752 error message chris hoina senior product manager ords database tools oracle

    You can clearly see that the database starts to provision, and then it just craps out1. I’ll spare you most of how we (I write “we” because this stuff is never really resolved by just one person) fixed this issue. But we finally figured it out; I’ll include some brief background. If you don’t care and want to see the resolution, then 👇🏼

    1craps out is a technical term used by only the upper-most echelon of technical masters and internet luminaries.


    Looking back, that Using default pga_aggregate_limit of 2048 MB line makes A LOT more sense now.

    About podman machines

    When you initiate a Podman machine, the default CPU and memory settings are 1 and 2048 MB (or 2,147,483,648 Bytes), respectively. I don’t see this in the documentation anywhere, but it is consistent with my assumptions when I created a second test podman machine with the default settings. 

    test podman machine with default settings chris hoina senior product manager ords database tools oracle
    The test machine with default settings

    After a ton of reading online, tinkering with podman volumes, pouring through the open issues in the podman and Oracle container GitHub repositories, and bugging the hell out of Gerald, we finally figured out the problem. Gerald, quite astutely, asked to see my output from the podman info command.

    REMEMBER...this is the output from the original default configuration of my podman machine. The one where I already had a 21c database container. So, briefly ignore that test podman machine.
    choina@choina-mac ~ % podman info
    host:
     arch: amd64
     buildahVersion: 1.31.2
     cgroupControllers:
     - cpuset
     - cpu
     - io
     - memory
     - hugetlb
     - pids
     - rdma
     - misc
     cgroupManager: systemd
     cgroupVersion: v2
     conmon:
      package: conmon-2.1.7-2.fc38.x86_64
      path: /usr/bin/conmon
      version: 'conmon version 2.1.7, commit: '
     cpuUtilization:
      idlePercent: 99.75
      systemPercent: 0.12
      userPercent: 0.13
     cpus: 1
     databaseBackend: boltdb
     distribution:
      distribution: fedora
      variant: coreos
      version: "38"
     eventLogger: journald
     freeLocks: 2046
     hostname: localhost.localdomain
     idMappings:
      gidmap: null
      uidmap: null
     kernel: 6.4.15-200.fc38.x86_64
     linkmode: dynamic
     logDriver: journald
     memFree: 1351737344
     memTotal: 2048716800
     networkBackend: netavark
     networkBackendInfo:
      backend: netavark
      dns:
       package: aardvark-dns-1.7.0-1.fc38.x86_64
       path: /usr/libexec/podman/aardvark-dns
       version: aardvark-dns 1.7.0
      package: netavark-1.7.0-1.fc38.x86_64
      path: /usr/libexec/podman/netavark
      version: netavark 1.7.0
     ociRuntime:
      name: crun
      package: crun-1.9-1.fc38.x86_64
      path: /usr/bin/crun
      version: |-
       crun version 1.9
       commit: a538ac4ea1ff319bcfe2bf81cb5c6f687e2dc9d3
       rundir: /run/crun
       spec: 1.0.0
       +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
     os: linux
     pasta:
      executable: /usr/bin/pasta
      package: passt-0^20230908.g05627dc-1.fc38.x86_64
      version: |
       pasta 0^20230908.g05627dc-1.fc38.x86_64
       Copyright Red Hat
       GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
       This is free software: you are free to change and redistribute it.
       There is NO WARRANTY, to the extent permitted by law.
     remoteSocket:
      exists: true
      path: /run/podman/podman.sock
     security:
      apparmorEnabled: false
      capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
      rootless: false
      seccompEnabled: true
      seccompProfilePath: /usr/share/containers/seccomp.json
      selinuxEnabled: true
     serviceIsRemote: true
     slirp4netns:
      executable: /usr/bin/slirp4netns
      package: slirp4netns-1.2.1-1.fc38.x86_64
      version: |-
       slirp4netns version 1.2.1
       commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
       libslirp: 4.7.0
       SLIRP_CONFIG_VERSION_MAX: 4
       libseccomp: 2.5.3
     swapFree: 0
     swapTotal: 0
     uptime: 10h 20m 12.00s (Approximately 0.42 days)
    plugins:
     authorization: null
     log:
     - k8s-file
     - none
     - passthrough
     - journald
     network:
     - bridge
     - macvlan
     - ipvlan
     volume:
     - local
    registries:
     search:
     - docker.io
    store:
     configFile: /usr/share/containers/storage.conf
     containerStore:
      number: 1
      paused: 0
      running: 0
      stopped: 1
     graphDriverName: overlay
     graphOptions:
      overlay.mountopt: nodev,metacopy=on
     graphRoot: /var/lib/containers/storage
     graphRootAllocated: 106769133568
     graphRootUsed: 45983535104
     graphStatus:
      Backing Filesystem: xfs
      Native Overlay Diff: "false"
      Supports d_type: "true"
      Using metacopy: "true"
     imageCopyTmpDir: /var/tmp
     imageStore:
      number: 2
     runRoot: /run/containers/storage
     transientStore: false
     volumePath: /var/lib/containers/storage/volumes
    version:
     APIVersion: 4.6.2
     Built: 1694549242
     BuiltTime: Tue Sep 12 16:07:22 2023
     GitCommit: ""
     GoVersion: go1.20.7
     Os: linux
     OsArch: linux/amd64
     Version: 4.6.2

    I included line numbers so you could more easily scan. Again, this output is from when I had a default podman machine. With this machine, I also had a 21c database container with a volume attached to it. I HAVE NO IDEA what the implications are of attaching volumes to containers (as far as memory is concerned)! I also don’t know what it does to the memory of the Linux virtual machine (what your podman machine actually is) 😬. 

    A closer look at the machine configuration

    Take a look at lines 39 and 40; you’ll see

    memFree: 1351737344 
    memTotal: 2048716800

    1351737344 Bytes equals 1.35 GB, while 2048716800 is equivalent to 2 GB. That is consistent with what you see in the podman machine’s default settings. And given that I have a 21c database container with a volume attached, that used memory (696979456 or 0.7 GB) could, at least partly, be attributed to the existing container.

    Aaaand…that earlier default pga_aggregate_limit of 2048 MB (read more here) line further supports the assumption that insufficient memory (in the podman machine) is the culprit. The way I read it, that database could consume as much as 2 GB of memory.

    So, how could I expect to create another container of equal size in a machine that is only large enough to support one container?! 

    Myself

    Resolving the unhealthy issue

    Well, after completely removing my podman machine, I re-initiated a new one with the following parameters (docs here): 

    podman machine init --cpus=2 --memory=4096
    NOTE: podman memory allocation is done in Megabytes. So 4096 Megabytes is equal to 4 Gigabytes.

    I then recreated two separate volumes, 21cvol, and 23freevol. From there, I created a container for the 21c database using the following command (sorry, I didn’t get a screenshot of this one):

    podman run -d --name 21entbd -p :1521 -v 21cvol:/opt/oracle/oradata container-registry.oracle.com/database/enterprise:latest

    And then another for the 23c database:

    podman run -d --name 23freedb -p :1521 -v 23freevol:/opt/oracle/oradata container-registry.oracle.com/database/free:latest

    And FINALLY, as you can see in the following image, both containers show a healthy status!

    both machines running chris hoina senior product manager ords database tools oracle
    NOTE: I've yet to sign into either of these databases, and I still have to reinstall ORDS in each. So if you are following along, this is where I leave you.

    Inspecting the new machine

    And just for fun, I inspected the sole podman machine (after removing that temporary test machine) to review its configuration.

    podman machine inspect chris hoina senior product manager ords database tools oracle

    In conclusion

    After about a week, I’m NOW ready to start working in the 23c container. We have some great new functionality and other ORDS stuff planned, too. I plan to start sharing that here!

    One more thing

    I’m bringing these findings up with the Oracle Container Registry team. I’ll probably share with the podman squad too. I feel I’m not alone in having trouble figuring out what the hell is going on under the covers.

    If you found this useful, please share the post! This one is more of a Public Service Announcement than anything else. I can’t tell you how frustrating it is when you can’t figure out why something isn’t working.

    Hey, I hope this expedites your misery, though 🙃!

    Follow

    And don’t forget to follow, like, subscribe, share, taunt, troll, or stalk me!