TL;DR: Starting with Free Edition release 23.26.1, database startup results in ORA-00600 [ksipc: no private ips avail for use] and instance crash if no IPv4 IP address is assigned. This is likely a newly introduced bug as 23.26.0 and below start successfully without a network (minimal networking). Manually adding an IPv4 to the downed interface resolves the problem.
Full details:
A colleague pointed out that Free Edition release 23.26.2 was failing to start, and was actually getting an ORA-00600, if started on a machine without a network. Earlier versions, up to and including 23.26.0.0.0 work fine with only a loopback adapter.
Testing the 26ai versions of Free Edition without a network resulted in:
- Version 23.26.2.0.0 - ORA-00600, database cannot be started
- Version 23.26.1.0.0 - ORA-00600, database cannot be started
- Version 23.26.0.0.0 - works as expected & database starts successfully!
The actual error from the alert log is:
ORA-00600: internal error code, arguments: [ksipc: no private ips avail for use], [], [], [], [], [], [], [], [], [], [], []
And there is a resulting trace file, but providing it here is probably uncessessary as this problem is easily reproducable.
Steps to reproduce:
- Installing Free Edition 23.26.2 into a VM (Running Oracle Linux 8.10) in VirtualBox
- Shutdown VM
- Uncheck the "Cable Connected" checkbox in the VirtualBox network adapter configuration
- Restart the VM and either let the service, or manually try to start the database --> ORA-00600 will be encountered and database will fail to start
Under such a scenario, the network configuration will look similar to:
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 08:00:27:64:8b:1a brd ff:ff:ff:ff:ff:ff
To bypass the ORA-00600 and have the database start, all that's required is to assign an IPv4 IP address to the interface. The interface doesn't even need to be started. For example:
# sudo ip addr add 10.0.2.15/24 dev enp0s3
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 08:00:27:64:8b:1a brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 scope global enp0s3
valid_lft forever preferred_lft forever
Now it has an IP address while still without a carrier. And we can leave the interface physically down but now that the interface owns an IP address, the database will start normally.
This seems to be a newly introduced 23.26.1 and above bug IMO as my testing conclusions are:
- Situtation is completely and easily reproducible (on physical or virtualized systems)
- Setting cluster_interconnects=':' has no effect
- Resetting local_listener has no effect
- Adding an IPv4 address to a non-loopback interface fixes it immediately
- Adding an RFC1918 address to lo does not fix it
- Adding only IPv6 to the interface does not fix it
- A physical carrier is not required
And as stated already, this issue is not encountered with versions 23.26.0 and below.
Could someone from Oracle kindly confirm and perhaps a bug can be opened?
Thanks!
Simon