I exported a database and it created a sql file for me with create and insert but I get an error saying ORA-02199: missing DATAFILE/TEMPFILE clause
in sql plus I run the sql script and get a bunch of ORA-00942: table or view does not exist Then i noticed when it creates a table it has TABLESPACE "LOCALDEV" ; So I enter CREATE tablespace LOCALDEV
Prior to all that I enter create user localdev identified by localdev;
and
grant ALTER SESSION, CREATE SESSION, CREATE DATABASE LINK, CREATE MATERIALIZED VIEW, CREATE PROCEDURE, CREATE PUBLIC SYNONYM, CREATE ROLE,CREATE SEQUENCE, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, CREATE VIEW, UNLIMITED TABLESPACE to localdev;
SQL> create tablespace localdev datafile '/u01/app/localdev.dbf'
size 100m;
ERROR at line 1:
ORA-01119: error in creating database file '/u01/app/localdev.dbf'
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
Additional information
: 1
I get no error until I run the sql script. If I had a BDA to ask I would but do not. Any advice will be greatly appreciated.
I exported a database and it created a sql file for me with create and
insert but I get an error saying ORA-02199: missing DATAFILE/TEMPFILE
clause (bla bla bla)
In my opinion, the very first step you did was wrong. If you wanted to export the "database" (I presume it is, actually, a "schema" (i.e. "user")), then you should have done that. Oracle offers Data Pump utility, export and import.
If you performed export, you'd take the DMP file with you and import it into another database using import data pump with the REMAP_TABLLESPACE parameter which accepts two values: the old, "source" tablespace and the new, "target" tablespace, separated by colon. For example:
impdp scott/tiger#new_database REMAP_TABLESPACE=localdev:users DIRECTORY=dump_dir DUMPFILE=scott.dmp
Alternatively, as you currently have a textual file that contains CREATE & INSERT statements, why didn't you open it in any text editor and replaced the old tablespace name (localdev) with a tablespace name used in your new database (that would be "users" in my IMPDP example)?
It takes a few seconds, you run it, everything gets created and you don't have to reinvent the wheel by doing everything you did after the first sentence (that would be bla bla part).
Related
I am using oracle 12c and I'm having a little trouble trying to attribute tablespace to a user.
Here is the error I got when processing the current DDL statement in pluggable database ORAPDB1:
the tablespace 'INTERVENTION_TBS' does no exist
Note that the tablespace was created successfully. So could someone suggest a solution please?
For more details I used this syntax query
CREATE USER c##DBAINTERVENTION
Identified by interventiondb
Default Tablespace INTERVENTION_TBS
Temporary Tablespace INTERVENTION_TempTBS;
run the following statements:
alter session set "_ORACLE_SCRIPT"=TRUE;
ALTER USER [username] IDENTIFIED BY [password];
You are trying to create a common user which will have access to all the PDBs in a CDB. As the user has access to all PDBs it can also create an object on those PDBs hence we need tablespace to create the objects. This is the reason why you need to have the tablespace specified in the CREATE USER command on all PDBs.
Please verify that you the INTERVENTION_TBS tablespace exists on all PDBs using the following query.
select cp.pdb_name
from cdb_pdbs cp join v$tablespace tb on(cp.con_id=tb.con_id)
where tb.name='INTERVENTION_TBS';
This query list all the PDBs which has the tablespace. If this tablespace doesn't exist on one of your PDBs then create one.
SQL> alter database drop tablespace XXX including contents and datafiles;
alter database drop tablespace XXX including contents and datafiles
*
ERROR at line 1:
ORA-01900: LOGFILE keyword expected
Note : I do not have datafile regarding this tablespace I have deleted it manually.
Please advice me and also if any article regarding backup tablespaces please share
You seem to be mixing up syntax from different commands. drop tablespace is a standalone statement:
The alter database statement is separate; it has a drop logfile clause, but not drop tablespace. The parser is seeing the drop ... in your statement and is expecting the next word to therefore be logfile - and since it isn't, it generates the error you see.
So you only need to do:
drop tablespace XXX including contents and datafiles;
(assuming you're really sure you do want to get rid of it permenantly, of course!)
The Oracle new tablespace name must fit with the old tablespace name?
For example:
The dump file tablespace name is A,and i create a new tablespace B,and it could import table, but has many error?
ORA-00959:tablespace 'ECASYS'(old) not exits.
This is my import statement:
imp userid='ZHPE/zhpe#ORCL' file='E:\xxxx\xxxx2013-08-15Bak\130815.dmp' log='D:\app\Administrator\oradata\orcl\ZHPE.log' full=y ignore=y;
Is the new tablespace must must must fit the old one???
help!
If you're forced to use the legacy exp and imp tools then the tablespace cannot be changed during the import itself using command-line options. If you can, switch to using the datapump versions, expdp and impdp, and then follow #schurik's advice.
If you can't do that then you'll need a workaround, which is to create the schema objects manually first.
If you run imp with the indexfile option then it will create a file containing the DDL for the tables and indexes:
imp user/password indexfile=schema.sql file=...
The table creation DDL is commented out with REM markers, which you need to remove. You can then edit it to change the tablespace and any other storage options that are no longer appropriate. Then run that schema creation SQL to create all the tables as empty.
Then run the normal import again, but with the ignore=y flag so it doesn't complain (much) that the tables now already exist. The data will still be inserted into those existing tables.
This will be a bit slower if you create the indexes as well as the tables beforehand; normally it would create the tables, insert the data, and then build the indexes, which is more efficient. If the slowdown is significant then you can split your schema.sql into separate table and index creation files and do the same thing manually - create the tables, run the import with ignore=y and indexes=n (to stop it trying and failing to create them), and then create the indexes yourself afterwards.
Clearly this is a bit of a pain, and one of many reasons that switching to datapump is a good idea.
take a look at the REMAP_TABLESPACE import parameter e.g
REMAP_TABLESPACE=A:B
This question is related to the one I posted yesterday but with further implications.
The situation is: I'm unable to drop ANY table. Here's an example:
SQL> CREATE TABLE FOO (BAR NUMBER) TABLESPACE SYSTEM
/
Table created.
SQL> SELECT COUNT(1) FROM FOO;
COUNT(1)
----------
0
SQL> DROP TABLE FOO;
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
ORA-06512: at line 19
So, the table seems to exist but I'm not capable of dropping it.
Notice the error ORA-00604: error occurred at recursive SQL level 1. If I try to drop a non existing table, this error does not appear:
SQL> DROP TABLE NON_EXISTING_TABLE
ERROR at line 1:
ORA-00942: table or view does not exist
Somehow, the system is unable to find the table at dropping time.
The oracle installation and the DB itself is new (one day old).
EDIT - I retried this test using another tablespace and user (I just created ones) and I got a slightly different behaviour: using SYS, after I got the DROP error I can still SELECT from the table. However, using this new user, after I got the DROP error, I no longer can SELECT from the table.
Solution
We found the problem: the MDSYS.SDO_GEOR_SYSDATA_TABLE was missing, preventing the drop operation.The solution is to restore that table. Here is the complete solution, by Gaurav Soni (by the way, many thanks).
Run the script catmd.sql (located in $ORACLE_HOME/md/admin dir).
The catmd.sql script is the script that loads all objects needed by Oracle spatial in the database. Then drop the user.
you can also refer to oracle metalinks
Steps for Manual Installation of Oracle Spatial Data Option
Dropping user results in ORA-942 against SDO_GEOM_METADATA_TABLE
I'd suggest that you activate SQL tracing (ALTER SESSION SET SQL_TRACE=TRUE;) and try the drop again. This will generate a trace file on the server (in the udump directory) that will show all the SQL the session executed, including recursive statements. This should show you the recursive SQL statement that is failing.
I think the problem is that you created the table on system tablespace. You should create it on the user tablespace or create one to store your data.
I have a table in Oracle for users. I am going to install new schema and want to backup all users with passwords and other fields.
I tried exp and int utilities, but imp doesn't recover anything.
I created temporary user in USERS table. Then I did backup with command:
exp user_owner/password file=file.dmp table=USERS rows=yes indexes=no
After that I deleted the temporary username and I tried to restore with:
imp user_owner/password file=file.dmp table=users fromuser=user_owner
Export file created by EXPORT:V10.02.01 via conventional path
import done in UTF8 character set and AL16UTF16 NCHAR character set
. importing USER_OWNER's objects into USER_OWNER
. importing USER_OWNER's objects into USER_OWNER
IMP-00015: following statement failed because the object already exists:
bla
bla
bla
Import terminated successfully with warnings.
In the USERS table temporary user didn't appear.
Please advice how can I perform such task like backup and restore rows (with values) of the table in Oracle.
Use IGRNORE=Y as a parameter to your import. This will ignore creation errors.
Type imp help=y at the command line for more information.
The specific error you got on import is because by default it will try to create the table, not just the data in it. You can use the IGNORE=Y flag to avoid that problem. But it will try to insert all the users that existed, not just the one you deleted, which might cause you other problems. Or, it could fail for those rows if there's a unique index.