When I deploy my asp.net application,I have to create some tablesapces/users,I use the pqsql,however I want to know is there any way I can create them with batch processing?
For example,I can execute this ddl:
create tablespace TSA.....
Then I can execute:
create user a ... default tablespace TSA...
But when I execute them at the same time:
create tablespace TSA.....
create user a ... default tablespace TSA...
I will get an error.
ANy way?
update
Error is something like this:
ORA-02180: invalid CREATE TABLESPACE words
BTW,I run the sql batches in the sql window of the pl/sql developer.
Now,I just want to know if there is any way I can run a whole ddl sql file?
Suppose this is the content of the init.sql:
create smallfile tablespace "DEV" datafile 'f:\app\administrator\oradata\orcl\dev01.dbf' size 100m autoextend on next 10m maxsize unlimited logging extent management local segment space management auto default nocompress
-- Create the user
create user dev_sa
identified by "000000"
default tablespace DEV
temporary tablespace TEMP;
-- Grant/Revoke role privileges
grant connect to dev_sa;
grant dba to dev_sa;
--create another tablespace
--.....
How to execute it in the batch process model?
If you have the two statements in a file you're running from SQL*Plus, you need to separate the statements with the / character, which also causes each to be executed
create tablespace TSA ...
/
create user a ... default tablespace TSA
/
(That's quite a big 'if', of course as per #APC's comment; but is something that's come up before. As has different ways of running things in SQL Developer, among other things. But really no more than a guess from the minimal info given...)
You have a semi-colon ; missing off the end of your first CREATE TABLE
Related
I'm using a procedure which creates a table using a heavy query (running ~1 hr). Query is something like 'select * from table', and the columns in the table can change.
Oftentimes it turns out that there is no free space in schema to create the table, so I get an exception, the time is spent in vain and I need to do the same calculations once again.
The error I get:
ORA-01536: space quota exceeded for tablespace
ORA-06512: at "UPDATE_REPORT", line 37
What I would want to do:
- Store query's results in temporary segment in a cursor;
- Try to create table using cursor. In case of exception (not enough space), drop a special space-holding table to free table space in schema;
- Try to create the table again from cursor.
I tried to solve this using dynamic SQL, but it leads to overcomplications while the problem seems to have a simple solution. And the main problem I faced is that there is no evident way to create a table using cursor.
Is there any simple solution I somehow missed out? Maybe cursor are the wrong way to work this out?
Two things I can think of:
let the database do the dirty job
a.k.a. enjoy your DBA job, simply by looking at Oracle administering itself
how? let tablespace autoextend
grant unlimited quota on that tablespace to user
Here's how (connected as a privileged user):
SQL> select file_name, tablespace_name From dba_data_files;
FILE_NAME TABLESPACE_NAME
------------------------------------------------ -----------------------------
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF USERS
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSAUX.DBF SYSAUX
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\UNDOTBS1.DBF UNDOTBS1
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF SYSTEM
SQL> alter database datafile 'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF'
2 autoextend on
3 maxsize unlimited;
Database altered.
SQL> alter user scott quota unlimited on users;
User altered.
SQL>
What I would want to do: - Store query's results in temporary segment in a cursor; - Try to create table using cursor. In case of exception (not enough space), drop a special space-holding table to free table space in schema; - Try to create the table again from cursor.
Don't go through the trouble. Just tell Oracle not to die because of space issues.
You can make your session "resumable" so that, rather than giving you an error when you run out of space, Oracle will suspend your session until the problem is corrected (and then continue on automatically).
Assuming you have all the permissions you need (notably, GRANT RESUMABLE TO yourschema), you enable it like this:
alter session enable resumable timeout 1800 name 'your process name, can be anything';
The 1800 number is in seconds, giving your DBA's 30 minutes to fix the problem before your session times out. The "my process" will show up in V$RESUMABLE for use in queries and automated alerts.
Your DBAs can monitor V$RESUMABLE and/or you can create a schema-level database trigger on the AFTER SUSPEND event to fire off an e-mail to them when they need to jump in.
I agree with #OldProgrammer - this is a design problem. Dropping and re-creating tables is an anti-pattern.
It's not clear what exact problem you're trying to solve, but a more sensible approach might be:
Create the table once. Use INITIAL EXTENT parameter to ensure that the table has all the space it needs (you may have to run some queries to establish what that figure should be).
Check with your DBA that the tablespace is set to AUTOEXTEND, in case there are rogue result sets which exceed your calculations. Maybe negotiate more tablespace quota for the schema owner.
Populate the table once.
Before subsequent runs, TRUNCATE the table using the REUSE STORAGE clause to hold on to the assigned space.
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!)
I execute a SQL query with hibernate and the application give the error:
ORA-01652: unable to extend temp segment
The TABLE SPACE has 4 GB.
The strange thing is that the query from the application yesterday was working fine, and today it doen't work.
I have not made any changes either in the database or application.
The oracle version is Oracle 11g
You are running short on space in temp tablespace , use this query t check how much space you have in your temp tablespace
SQL> select file_name,SUM(bytes)/1024/1024 "Current_size_mb", sum(maxbytes)/1024/1024 "max_size_mb" from dba_temp_files group by file_name;
FILE_NAME Current_size_mb max_size_mb
---------------------------------------------------------------------- --------------- -----------
C:\AKS\AKDB\ORADATA\RESEARCH\TEMP01.DBF 20 32767.9844
Adding a new tempfile to temp tablespace
SQL> alter tablespace temp add tempfile 'C:\AKS\AKDB\ORADATA\RESEARCH\TEMP02.DBF' size 100m autoextend on maxsize 1g;
Temporary tablespace called TEMP which is used internally by database for operations like distinct, joins,etc to fetch large amount of data.
So, after increasing the size of TEMP tablespace the issue can be resolved.
Follow this link : How to shrink temp tablespace in oracle?
Unfortunately one UNDO data file was misplaced in wrong location when I was adding space. I want to move that file to correct location. As it is Production database, I don't want to disturb the ongoing transactions. Can I offline that particular undo data file, while moving... will Database work normally with zero data loss?
Version Of Oracle DB: 11.2.0.4.0
can any one suggest?
During database running and in 24/7 environment, you should need to create new undo tablespace with new location of undo datafile. After creating this newer tablespace, you can switch older to newer undo tablespace online without affecting any ongoing transactions.
Following example shows how to achieve your goal. Using this trick, you can avoid data loss.
SQL>create undo tablespace undotbs2 datafile '/yournewlocation/undotbs02.dbf' size 1000m;
Now set new undo tablespace as default undo tablespace using following command as SYSDBA in SQLPLUS
SQL> alter system set undo_tablespace= undotbs2 ;
After finishing above task you can drop old undotbs tablespace from database using following command.
SQL> drop tablespace undotbs including contents;
I would consider creating the undo tablespace as a BIGFILE datafile:
CREATE BIGFILE UNDO TABLESPACE UNDOTBS02
DATAFILE '/yournewlocation/UNDOTBS02.dbf'
SIZE 100M AUTOEXTEND ON NEXT 100M
MAXSIZE 500G; --or whatever size you consider sufficient for your DB
I would also alter the system with a scope of BOTH, to make sure the change is made in both memory and spfile:
ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS02 SCOPE=BOTH;
Then, provided all active transactions and the UNDO_RETENTION period (if any) are done, you'll be able to drop the tablespace as described by doc123.