If you are using the old imp method the users and tablespaces must be created first. This includes grants, database links and any advanced queues you may be using. A sample script could look like this in Windows
imp a_DBA_user/apassword LOG =C:\dump\logs\import.log file =user01.dmp fromuser=user_name touser=user_name
The newer datapump method works wonderfully. You don't need to create the user but I would create any custom tablespaces you may have on the original.
A sample data pump call requires you to create a database link to the original database and a directory. This creates a directory
CREATE OR REPLACE DIRECTORY
DATA_PUMP_DIR AS
'C:\app\Oracle\product\11.2.0\dbhome_1\rdbms\log\';
GRANT READ, WRITE ON DIRECTORY DATA_PUMP_DIR TO EXP_FULL_DATABASE;
GRANT READ, WRITE ON DIRECTORY DATA_PUMP_DIR TO auser;
GRANT READ, WRITE ON DIRECTORY DATA_PUMP_DIR TO IMP_FULL_DATABASE;
In your script to import set these variables
NLS_LANG
ORACLE_SID= your database name
impdp a_user_who_exists/your database name directory=DATA_PUMP_DIR network_link=original database name schemas= user1,user2 LOGFILE=DataPump.log TABLE_EXISTS_ACTION=REPLACE
Ok ! Let me describe how this issue was solved:
1) There was definitely a corruption issue caused by a problem with vmware tools on solaris 10. When the network interface had high transfer/load operations (sample: copy of a 2 GB DB ....), it just stoped working, in the middle of the operation. To put the interface working again, I had to disconnect and connect the network interface again (in the vmware interface !).
Basically, I had to unistall vmware tools on solaris virtual machine.
There was one catch, the highest transfer rates that could be achieved was about 300 Kb. Basically I could take hours to perform a simple ftp transfer of a 2 GB database, but there wasn´t any corruption at all.
How to prove/test that there is/inst´t any corruption. I just packed (on the source machine) the database dump into a tar file (yes, an extra 20kb), but after the download complete, on the target server, I was able to untar the file, and if the untar operation was sucessfull that proved that there wasn´t any corruption on the file that was just transfered.
2) After being sure that the dump was ok, I got a diferent error:
Apr 17 14:24:20 2012: Backup Server: 4.188.1.1: Database wfcv2: 158936 kilobytes (1%) LOADED.
Apr 17 14:24:47 2012: Backup Server: 4.188.1.1: Database wfcv2: 303212 kilobytes (2%) LOADED.
Apr 17 14:25:16 2012: Backup Server: 4.188.1.1: Database wfcv2: 447104 kilobytes (3%) LOADED.
Apr 17 14:25:39 2012: Backup Server: 4.124.2.1: Archive API error for device='compress::1::/data4/20120413_wfcv2_zdump::000': Vendor application name=Compress API, Library version=1, API routine=syb_read(), Message=syb_read: gzread() error=0, msg=Error 0
Apr 17 14:25:39 2012: Backup Server: 4.124.2.1: Archive API error for device='compress::1::/data4/20120413_wfcv2_zdump::000': Vendor application name=Compress API, Library version=1, API routine=syb_close(), Message=syb_close: gzclose() error=-3 msg=Input/output buffer is corrupt
Apr 17 14:25:39 2012: Backup Server: 6.32.2.3: compress::1::/data4/20120413_wfcv2_zdump::000: volume not valid or not requested (server: , session id: 20.)
Apr 17 14:25:39 2012: Backup Server: 1.14.2.4: Unrecoverable I/O or volume error. This DUMP or LOAD session must exit.
Ok ! Sybase configuration issues !
I had to configure some parameters that were related to load operations, such as:
number of large i/o buffers -> 32
max memory
And a Solaris issue !
I also had to adjust the Operating System Shared Memory to the sybase engine ... !
And I finally was able to load the DB (size > 2.1 GB) !
;-) Cheers !
Best Answer
Reinstalling Oracle XE did the job.