ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-31640: unable to open dump file "/nav_db_dir/cmODF_odf_nav_db/ashsahu/gabq418/RDF_ANT_181G0/RDF_WTA_181G0_ANT.dmp" for read
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Below is my command I have created directory DirectoryName Path directoryObject /import/datatest
impdp username/password#sid table_exists_action=REPLACE tables=SCHMEA.TABLE1,SCHMEA.TABLE2, SCHMEA.TABLE3, SCHMEA.TABLE4, SCHMEA.TABLE5 DIRECTORY=directoryObject remap_schema=SCHMEA:username remap_tablespace=SCHMEA_DA:username_DA dumpfile=file.dmp exclude=grant nologfile=y
And I have given the full access to this directory using chmod 777 /import/datatest (rwxrwxrwx) –
You should have posted the whole IMPDP command.
I suspect that you misunderstood/misused the DIRECTORY parameter.
It is an Oracle object, created by SYS, and is only (generally speaking) a "pointer" to a physical directory on the database server's hard disk. After it is created, SYS should give you (i.e. the user which is running the IMPDP command) read (and, possibly, write) privileges on that directory.
Then you'd use it as
impdp scott/tiger#orcl directory=IMP_DIR dumpfile=mydump.dmp logfile=imp.log
----- -------
is granted READ privilege |
directory object
Finally, mydump.dmp (or whatever its name is) must reside in that directory on the server.
To add to what #Littlefoot said
Example:
Create directory datapump as '/import/datatest';
Grant read,write on directory datapump to scott;
And then the dump file should reside # /import/datatest
Make sure also that the username that Oracle is running as, let's say "oracle", has access to both the "/import" directory, and the "/import/datatest" directory. Make sure that the user can "cd" into /import/datatest
Related
I am using data pump to perform an import on 4 .dmp files and keep on receiving the set of errors as below:
ORA-39002: invalid operation
ORA-39070: Unable to open the log file.
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 536
ORA-29283: invalid file operation
I am new to oracle and cannot find a helpful solution.
I am performing the import as in here, although I'm using oracle 12c.
The command I run in the windows command like looks like this:
impdp user/pass#db_name directory=DUMP_DIR dimpfile="file_name.dmp" schemas=schema_name content=all parallel=4
DUMP_DIR is created in oracle and appropriate privs were granted.
I also ran this command with
... logfile=file_name.log
added at the end but I'm not sure if the log file was created or where it was saved.
I have found this - it's about exactly the same set of errors but on export and on linux. At the end of the answer there's a sentence 'If we are on a Windows machine, then we need to make sure that both the listener and the database have been started with the exact same username.' Is this useful in case of import? If yes - what does it mean exactly?
There's a great short answer here, which is basically "The database isn't able to write to the log file location."
The link above suggests a simple test to troubleshoot the issue.
declare
f utl_file.file_type;
begin
f := utl_file.fopen ('DUMP_DIR', 'test.txt', 'w');
utl_file.put_line(f, 'test');
utl_file.fclose(f);
end;
/
If this fails, Oracle can't write to that directory at all, probably because of Windows file permissions. Check which Windows user(s) the Oracle services are running as, and change the folder permissions to allow them write access.
If that worked, it's a problem specific to impdp. You might try changing your command string - one option might be to specifically write your log file to a different Oracle directory, e.g. logfile=DATA_PUMP_DIR:file_name.log.
If none of these options work, you can also disable the logfile completely by using NOLOGFILE=Y, but you'll have to monitor the impdp output on your console, because it won't get saved anywhere else.
The problem You have is Your Oracle is not able to write to DIRECTORY (DUMP_DIR) you specified.
In Windows 10, It behaves unpredictably. Solution
Create another Oracle directory with preferably in C:\Users\Public\ folder, where you are 100% sure access would not be issue. CREATE OR REPLACE DIRECTORY DUMP_DIR_2 AS 'C:\Users\Public\<name>
Give Grants GRANT READ, WRITE ON DIRECTORY DUMP_DIR_2 TO schema_name;
Copy your dump file to newly created folder.
Fire your import command
First is very important the Oracle have the permission to write and read the folder. If you already test this, try the solution bellow:
I had the same situation, in my case the command was (password is only for an instance) :
impdp 'sys/passExample as sysdba' directory=C:/oracle/oradata/EXEMPLODB dumpfile=preupd.bak
I put the preup.bak into the folder EXEMPLODB
The correct is change the directory folder by the name of directory, the correct command is:
impdp 'sys/passExample as sysdba' directory=EXT_DATA_FILES dumpfile=preupd.bak
The EXT_DATA_FILES is the directory name, I found with the query
select * from all_directories;
into the system db.
Update:
I tried the impdp command and it's giving me that it cannot create a user. I tried creating the user as well
This is how my .par file looks like
This is a snip of .sh file
I have never used the oracle database before. I have a .dmp file which is 50 GB. I don't know how it was exported or which version it was exported from. I downloaded Oracle 12c release 2 and tried to do an import but I get the error ".dmp may be a Data Pump export dump file". What do I need to do so that I can run SQL queries on it eventually? Please see the attached image.
UPDATE :
I tried the command :
IMP SYSTEM/Password SHOW=Y FILE=DBO_V7WRIGLEY_PROD_20180201_TECHOPS-5527.dmp fromuser=SYSTEM touser=SYSTEM
It gave me a message saying import terminated successfully with warnings. what does this do? Also, where can I view the data now if it's imported?
in sqlplus as SYSTEM:
CREATE DIRECTORY IMPDIR as 'C:\Users\negink\Documents\databasewrigley';
back in command line:
impdp SYSTEM/Password DUMPFILE=IMPDIR:DBO_V7WRIGLEY_PROD_20180201_TECHOPS-5527.dmp logfile=IMPDIR:DBO_V7WRIGLEY_PROD_20180201_TECHOPS-5527.log FULL=Y
when done, you can remove the DIRECTORY object
in a CDB database (which is your case), this will not work, unless you
pre-create all the users and roles in SQLPLUS, after running this command:
alter session set "_ORACLE_SCRIPT"=true;
create user x identified by pwdx;
create user y identified by pwdy;
create role r1;
create role r2;
...
Otherwize, you can create a PDB inside your CDB and import your DMP file into the PDB. In this case, you'll need to modify the connection in the IMPDP command as follows (change SYSTEM/Password to SYSTEM/Password#//localhost/pdb_name) :
impdp SYSTEM/Password#//localhost/pdb_name DUMPFILE=IMPDIR:DBO_V7WRIGLEY_PROD_20180201_TECHOPS-5527.dmp logfile=IMPDIR:DBO_V7WRIGLEY_PROD_20180201_TECHOPS-5527.log FULL=Y
First of all, you should use impdp instead of imp. And don't forget to take backups before doing anything. Also, you should have your dmp file on your server's local directory. I've seen people trying to import dmp files located on their computer's hard drive. That's not how things work.
I recommend you to drop the schema if you are importing to an existing schema for better results.
To drop an existing schema, login to sqlplus with an admin account
sqlplus username/password#connect_identifier
Then you can use this command to drop the schema:
DROP USER <SCHEMA_NAME> CASCADE;
Query your DB to see if data pump directory is defined
SELECT directory_name, directory_path FROM dba_directories WHERE directory_name='DATA_PUMP_DIR'
If directory is not defined use this command to define (btw "D:\orcl12" is my oracle instance path, you should use your own path)
CREATE OR REPLACE DIRECTORY DATA_PUMP_DIR AS 'D:\orcl12c/admin/<ORA_INSTANCE_NAME>/dpdump/';
Quit sqlplus to command prompt and run impdp with admin credentials (Be sure there's no other logfile with the same name on source directory - if so operation will abort)
impdp username/password#connect_identifier directory=DATA_PUMP_DIR dumpfile=filename.dmp logfile=filename.log
If the operation succeeds you may have to update User-Defined Datatypes manually because they are not importing correctly.
I am trying to import an oracle DMP file in windows. I try this:
impdp me/pass#mydb file=mydump.DMP
I get this error:
unable to open file /rdsdbdata/datadump/mydump.DMP
Now I am on windows so I don't know where that cam from. I also tried to set the directory like this:
impdp me/pass#mydb directory=C:\Oracle fiel=mydmp.DMP
that gives me a "invalid directory" error.
Some research also said to try this in SQL:
create or replace DIRECTORY DATA_DUMP_DIR AS 'C:\Oracle';
but that also gives me an invalid directory error.
How do I import this file on windows?
First of all, create a directory:
SQL> conn sys as sysdba
SQL> create directory dp_dir as 'C:\Oracle';
Grant READ and WRITE privilege to the user who is going to perform the import.
SQL> grant read, write on directory dp_dir to user;
Make sure that your dump file resides on the directory which is C:\Oracle.
Then run the impdp as:
impdp user#tnsname directory=dp_dir dumpfile=dumpfilename.dmp
Say, I have an oracle directory and granted to user 'scott'
CREATE OR REPLACE DIRECTORY dataFolder AS '/data/';
GRANT READ, WRITE ON DIRECTORY dataFolder TO scott;
Then, I have a shell script say ExtractData.sh which uses UTL_FILE to convert BLOB data from database to physical files stored in the above directory dataFolder.
However, due to security concern in server, this /data/ directory is only given 770 permission, hence causing my script fails to write file into the directory.
But, when I change the permission to 777, script successfully writes file.
How to solve this by not giving 777 permission?
You failed to mention the owner of the directory.
Use a directory owned by oracle or in the osoper or dba group and you won't need 777 permissions. Apparently the directory is owned by root or some other user, so owner and group bits aren't helping you.
You can use chown to change ownership.
chown oracle:osoper /data
Just make sure you are aware of other programs accessing /data, if you change ownership make sure to adjust privs accordingly.
With the help of Stack Overflow, I've been able to export a dump file of my database from my local machine. The command I used is as follows:
host expdp tkcsowner/tkcsowner#xe version=10.2 schemas=tkcsowner dumpfile=tnrg.dmp logfile=tnrg.log
Now, my local machine has the OS Windows 7, 32-bit. Hardly a server. It's got Oracle 11g. I want to transfer it to another machine, the test server, running Linux. It has Oracle 10g.
I am in no way a Linux / Unix expert, but I do have some instructions left for me by the previous person who handled such.
First, I change privileges to root user via 'su -' - No problems there.
Log in as 'sqlplus /nolog', and then 'connect sys/sys#xe as dba' - No problems there, either.
I created a logical dump directory (not sure if this step is needed, but I did it anyway):
create or replace directory dumpdir as 'usr/lib/oracle/xe/app/oracle/admin/XE/dpdump';
Done, no problems.
So I take it TNRG.dmp and tnrg.log should be inside that directory. Unfortunately, it could not be copied, for some reason. Access denied. I figured I should log out, log in as root, and copy the stuff from there. It worked, but just to be safe, I logged out of the root, logged back in as my normal user, and did everything above again. D'oh.
Finally, with all the stuff in place, now comes the time to import the .dmp and .log. Huzzah!
impdp tkcsowner/tkcsowner#xe schemas=tkcsowner dumpfile=TNRG.dmp logfile=tnrg.log
Lo and behold, it asks for a username and password. Is it because tkcsowners does not exist on the 10g database? Anyway, I put in 'system' for both. It continued, but warning bells already set off in my head.
Suddenly:
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
ORA-39002: invalid operation
ORA-39070: unable to open the log file.
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 475
ORA-29283: invalid file operation
At which point, I'm not sure how to proceed. I went into the directory via the command line, and ls -l'ed the contents, showing that both the .dmp and .log have three rwx's, for root. What I have yet to try was to run the entire operation while logged in as root, but I'm not sure how that would change anything.
The directory that your dumpdir database directory object points to needs to be a valid existing directory - at least by the time you use it, it won't check or complain when you create the object - and it needs to be readable and writable by the user that Oracle is running under, which is usually oracle.
Your initial directory creation had 'usr/lib/oracle/... rather than '/usr/lib/oracle/..., but even with that corrected the directory might not be usable by the oracle account. Since you created the directory as root, it is probably still owned by root:root and with permissions 700 (if you do ls -ld /usr/lib/oracle/xe/app/oracle/admin/XE/dpdump that will show as drwx------).
You need to change that to be owned by Oracle, using the correct owner and group - that's probably oracle:dba or oracle:oinstall, but check the owner of the XE directory. And then change the ownership of the directory and the files you copied into it:
chown -R oracle:dba /usr/lib/oracle/xe/app/oracle/admin/XE/dpdump
and set the directory permissions to a suitable level; if you don't want anyone else to create or modify files, but you don't mind them seeing what's there, then something like:
chmod 755 /usr/lib/oracle/xe/app/oracle/admin/XE/dpdump
If you want to be able to copy your .dmp file in as yourself (not root or oracle) and you aren't in the dba group then make it 777. You said the files you copied are 777, which is a little odd as they aren't executable, and could currently be removed by anyone; again to make them just readable:
chmod 644 /usr/lib/oracle/xe/app/oracle/admin/XE/dpdump/*
You don't need the export log from the other system though, just the dump file itself. The logfile parameter for impdp will create a log of the import process; since you used the same file name it will overwrite the export log you copied across. THat probably doesn't matter since you still have the original, but something to watch for in the future. It does mean the existing log file has to be writable by oracle though.
You also need to make sure the Oracle owner has appropriate access to the whole directory tree, but it seems likely that they already own XE so I don't think that's an issue here. You shouldn't really need to do any of this as root. If you don't have the oracle password you can su to the account from root anyway, which remove the need to manually change ownership later.
The impdp command is initiated from outside Oracle (probably with root in your case) but mainly executed by the Oracle server processes. In particular, the dump and log files are directly access by the Oracle server processes (and not by the initiating command). As a result, the file protection need to be set such that the oracle user can access them.
So execute the following (as root) and try again:
chown -R oracle:oinstall /usr/lib/oracle/xe/app/oracle/admin/XE/dpdump