Monthly Archives: January 2025


Slow starting impdp from NFS Share

Unfortunately I lost the logs for this issue, but I try to document for information.

My customer has ExaCC with various 2-node clusters.

  • Export ACFS mount point as NFS from cluster1
  • Mount NFS mount point on cluster2, cluster3 and cluster4

He did an export from cluster1 to the ACFS mount point.

All was working fine until mid December, when impdp reading a dumpfile from the NFS mount point seems hanging when was called from cluster3 and cluster4. From cluster2 it was still fine.

Few days later, the impdp was slow everywhere, except locally on cluster1.

The behavior was very bizarre:

  • impdp starting showing timestamp
  • exactly 5 minutes later first output comes “W-1 Startup took 1 second”
  • exactly 5 minutes after comes second line “W-1 Master table … successfully loaded/unloaded”
  • and 5 minutes later runs the rest, quickly.

The NFS mount point seemed ok, ‘dd’ command tests did not show any slowness.

I started to investigating by enabling the DataPump tracing, as explained by Daniel Hansen on his Databases are Fun blog:

alter system set events 'sql_trace {process: pname = dw | process: pname = dm} level=8';

The trace files generated on Diagnostics directory did not help much – they are mostly for performance problems.

Then I did start a “strace” on the PID of the impdp

strace -p <pid> -o /tmp/strace.out

There I could see some “ECONNREFUSED” to one of the IPs of the Cluster1. But few lines above, there was the same connection without error.

Quite strange. Finally with the help of one system administrator, we found out that the nfs-server was not running on one of the cluster1 nodes. And the NFS mount point was using a hostname which dynamically would go either to one or another node of the cluster1. After making sure nfs-server was running on both nodes from cluster1, the problem was solved and impdp was fast to start again.

Learnings:

  • Use the clusterware to manage exportfs – srvctl add exportfs
  • Make use of VIPs which move from one node to another instead of round-robin DNS entries.


ORA-64307 when creating compressed table and /home

My customer running on ExaCC (Exadata Cloud@Customer) was getting “ORA-64307: Exadata Hybrid Columnar Compression is not supported for tablespaces on this storage type” on one of his test databases.

I did test connecting to SYS and no problem. Then I try to do using his tablespace and indeed, I get the error:

Quite going around, to check what was different on the user tablespace than on others. I test a self created tablespace and it works.

Strange. Until I found that… some datafiles were not in ASM!

Seems the ASM Diskgroup is almost full and the client DBA just put the datafiles somewhere else!


JumpHost Matryoshka

My client just added an extra jumphost before arriving to the server. So now I’ve to connect, to connect, to connect and then open the connection. 🙂


Warning: OPatchauto ignores disabled components – possible licensing issues

Since many years at my customer I’m using “opatchauto” to perform a out-of-place patching of Oracle Restart (GI+RDBMS).

My customer is concerned about database users using not licensed options, like partitioning. To avoid it, at the installation time the partitioning option is disabled using chopt, like described at Doc ID 948061.1.

Today during a check we noticed that Partitioning option was activated everywhere, which is not the client standard! We found out the origin of the problem was the out-of-place patching with “opatchauto”.

The big advantage of using “opatchauto” is that it allows easily either a single-step or a two-step Out-of-Place patching. We just write in a properties file the name of the new Oracle Homes and it does:

  • Clone current GI + RDBMS homes to new Homes (prepare clone)
  • Patches the new homes (prepare clone)
  • Stops GI and DBs (switch clone)
  • Switches GI and DBs from current homes to new Homes (switch clone)
  • Restart everything (switch clone)
  • Runs Datapatch on DBs if not standby (switch clone)

This allows to decrease the patching downtime without RAC to about 10 minutes, with the two-step (prepare clone + switch clone) operation.

Here the steps to reproduce de bug:

(more…)