oracle / vagrant-projects

Vagrant projects for Oracle products and other examples
Universal Permissive License v1.0
946 stars 477 forks source link

impdp encounters read errors when importing a dump located on a VirtualBox Shared Folder. #419

Closed asteiner-psh closed 2 years ago

asteiner-psh commented 2 years ago

Describe the issue

impdp encounters read errors when importing a dump that's located on a shared folder.

  1. Add a shared folder by adding the following to Vagrantfile just before the last end: config.vm.synced_folder "/Volumes/Scratch_Space/DBDumps", "/DBDumps" , owner: "oracle", group: "dba"

  2. Provision the box with the following settings: env VM_SYSTEM_TIMEZONE='UTC' VM_ORACLE_SID='ORCL' VM_ORACLE_PWD='oracle' vagrant up

  3. SSH in, and switch to the oracle user using sudo su - oracle.

  4. Confirm that the oracle User can read and write to the Shared folder:

    ls /DBDumps
    echo 'world' >  /DBDumps/test.txt
    cat /DBDumps/test.txt
  5. Add the DBDumps directory to Oracle:

    sql -S -L system/oracle@ORCLPDB1 <<EOL_SQL
    CREATE OR REPLACE DIRECTORY DBDUMPS AS '/DBDumps';
    EOL_SQL
  6. Run the impdp with METADATA_ONLY: impdp system/oracle@ORCLPDB1 dumpfile="DBDUMPS:test.dmp" CONTENT=metadata_only

I get the following output:

[oracle@oracle-19c-vagrant ~]$ impdp system/oracle@orclpdb1 dumpfile="DBDUMPS:test.dmp" CONTENT=metadata_only

Import: Release 19.0.0.0.0 - Production on Thu Mar 3 18:45:28 2022
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
ORA-39002: invalid operation
ORA-31694: master table "SYSTEM"."SYS_IMPORT_FULL_01" failed to load/unload
ORA-31644: unable to position to block number 57658 in dump file "/DBDumps/test.dmp"
ORA-19501: read error on file "/DBDumps/test.dmp", block number 1 (block size=4096)
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 95: Operation not supported
Additional information: 4294967295
Additional information: 258048

If I copy the dump file to a disk on the VM (ensuring that oracle can read and write to the folder, and reconfiguring DBDUMPS), impdp works fine. So I know the file is not corrupted. I would like to avoid this workaround, however, for various reasons including disk size and performance (the dump files I work with are double to triple digit GBs).

Environment:

Additional information I also tried these steps with the v6.1.18 Guest Additions, and still got the error.

I also tried these steps with a manually added Shared Folder, and still got the error.

The process here (of importing a dump file located on a Shared Folder) is one that I've been using successfully for years on an older DeveloperDays VM (running 12.2) (https://www.oracle.com/downloads/developer-vm/community-downloads.html).

PaulNeumann commented 2 years ago

VirtualBox shared folders aren't really suited for Data Pump imports and exports. Searching for "VirtualBox shared folder slow" will yield a lot of results. There's a pretty good discussion in the VirtualBox forums here. The recommendation is to use VirtualBox shared folders only for copying files to and from the VM.

I'm surprised that you got this to work with the older Developer Day VM. I've never been successful using a VirtualBox shared folder for Data Pump operations--I always end up copying the dump file to or from the VM.

Since you're running macOS, you might try using an NFS synced folder (see the Vagrant documentation here). I haven't tried this, but NFS folders should perform better.

When working with very large dump files, keep in mind that the root volume for the base Vagrant box is only 32 GB. If you need more space, the Vagrantfile for the OLCNE project in this repository shows how to add another disk.

I hope this is helpful.

asteiner-psh commented 2 years ago

Thank you for responding.

I too saw posts about Shared Folders being slow, and after seeing this error, I was getting the feeling that the "vboxsf" modules weren't as feature-full as other network-share modules are.

I'm surprised that you got this to work with the older Developer Day VM. I've never been successful using a VirtualBox shared folder for Data Pump operations--I always end up copying the dump file to or from the VM.

I must have gotten lucky with my VM. As I said, been running imports over a Shared Folder for years with no issues.

As far as speed, the Shared Folder could have been slowing down the import, but it's something I never gave a thought to. When you're running a data-intense service like Oracle on top of Linux, that's running inside OSX (and a MacBook Pro no less!), you can't expect things to process at blazing speeds.

I will give the NFS synced folder a try.

Thanks again.