Im reading some Oracle scripts, and I found one with this
Create Table XXY(...)
Tablespace SOME_TABLESPACE
....
NOCOMPRESS
NOPARALLEL
..
What does this mean? What is if for? There are many CreateTable statemsnts, but the Tablespace statement after is exactly the same.
As I understand SOME_TABLESPACE must exist when this script is excecuted, but thats all I could get. Is the purpose of the statement to store all the tables in the same place?
EDIT
I read this
http://www.adp-gmbh.ch/ora/concepts/tablespaces.html
"Same place" doesn't quite describe it ...
A tablespace is a grouping of common data files. With your "Create" statements you can define in which tablespace an object gets stored. Usually different types of oracle objects are stored in different tablespaces that can have different capabilities.
Some examples:
"Data" (your tables and the rows stored in these tables) are stored in a different tablespace than "system information" (such as transaction logs or "caches"). This allows you to store system information on a local drive (quick, but somewhat limited in space) and data in a Storage Area network (basically unlimited space, but not quite as fast).
Table Data and Indexes can be stored in different tablespaces which may be on different disks. Therefore, table lookup and index lookup can use different disks and be faster than if both were on the same disk.
Tablespaces and their different characteristics are oen of the many ways of tuning an Oracle DB. Lots of capabilities, lots of complexity. If all you're doing is a little development machine, there is little need to worry about it.
It creates the table in that tablespace. In the case of partitioned tables it defines that tablespace as the default for new partitions and subpartitions also.
Please read:
http://download.oracle.com/docs/cd/B10501_01/server.920/a96524/c04space.htm
Related
I have a stored procedure where I use a cursor to loop through items in a temporary table:
OPEN CURSOR_SCORE_ITEMS FOR SELECT
ID_X, ID_Y
FROM
SCORE_ITEMS
GROUP BY
ID_X, ID_Y
HAVING
SUM(SCORE) > 10;
LOOP
FETCH CURSOR_SCORE_ITEMS BULK COLLECT INTO COMPARE_ITEMS LIMIT 100;
---loop over items and do stuff---
END LOOP;
CLOSE CURSOR_SCORE_ITEMS;
The procedure is working fine for instances where the 'SCORE_ITEMS' table is small, but for large tables (several millions of rows) I am receiving error
"ORA-01652: Temp-Segment kann nicht um 12800 in Tablespace TEMP_ALL
erweitert werden"
(sorry, its in German).
Note that SCORE_ITEMS is a temporary table which is generated earlier in the procedure. It seems that the cursor query is exceeding the size of the temp tablespace.
I read some solutions already that involve increasing the size of the tablespace but I do not have any privileges on this database so I do not think that is possible. Is there an alternative way, or some kind of preprocessing I might consider, that reduce the overhead in the temp tablespace?
Global Temporary Tables are written to TEMPORARY tablespace (that is, not the usual tablespace for heap tables). Do you have a separate temporary tablespace for GTTs? I suspect not. Most places don't.
So (assuming No), when SCORE_ITEMS has millions of rows you've already eaten a big chunk of TEMP. Then your query kicks off with an aggregation that is big enough to spill into TEMP - because GROUP BY needs sorting.
You have already ruled out the obvious solution:
increasing the size of the tablespace but I do not have any privileges on this database so I do not think that is possible.
I don't know whether this also rules out the radical idea of talking to your DBA and seeing whether they will increase the space allocated to TEMP, or - better - create a new tablespace for Global Temporary Tables.
The other thing to consider is whether you actually need TEMP_SCORE. It's not unusual for people to populate a GTT when they could just write a more efficient SELECT instead. There's a lot of overhead in a GTT - all that I/O to disk, not to mention contending for shared TEMP tablespace. It's definitely an option to consider.
I came across two code snippets :
one...
ALTER TABLE table_name
DROP CONSTRAINT constraint_name;
DROP INDEX index_name;
alter TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY (column, column)
USING INDEX TABLESPACE tablespace_name;
Two ...
CREATE INDEX index_name ON table_name (column_name)
TABLESPACE tablespace_name;
Now I can understand the statements that are not in bold but the statements in bold are quite difficult to understand. Why are we using tablespaces, especially in this context? What is the meaning of these two statements? Can someone give me a detailed answer with examples?
Thank you!
A tablespace is a logical storage unit. Actual OS storage is defined in datafiles, and datafiles are linked to a tablespace. This means that we can deploy database objects on different servers, different OS even, without needing to know the underlying directory structure.
As for index tablespaces, indexes are physical objects and need to be stored somewhere. These days it is not as common to distinguish between Index tablespaces and table tablespaces, because modern servers are raided, striped, etc so nobody need worry about disk heads.
In fact, Oracle's built-in tablespace management is so good that we can largely forget about tablespace planning altogether. There is still a case for having separate tablespaces for e.g. read-only data, transportable tablespaces, partitioning, etc.
We have a 60 GB production database in my new organization. We run closely 500 reports overnight from this DB. I notice that all the report scripts create tables in TempDB and then populate the final report. TempDB size is 6 GB. There is no dependency set up for these report scripts, which are called from PowerShell.
Is it a good practice to use TempDB extensively in this manner? Or is it better to create all the staging tables in the production database itself and drop them after the report is generated?
Thanks,
Roopesh
Temporary tables always gets created in TempDb. However, it is not necessary that size of TempDb is only due to temporary tables. TempDb is used in various ways
Internal objects (Sort & spool, CTE, index rebuild, hash join etc)
User objects (Temporary table, table variables)
Version store (AFTER/INSTEAD OF triggers, MARS)
So, as it is clear that it is being use in various SQL operations so size can grow due to other reasons also. However, in your case if your TempDb has sufficient space to operate normally and if your internal process is using TempDb for creating temporary tables and it is not an issue. You can consider TempDb as an toilet for SQL Server.
You can check what is causing TempDb to grow its size with below query
SELECT
SUM (user_object_reserved_page_count)*8 as usr_obj_kb,
SUM (internal_object_reserved_page_count)*8 as internal_obj_kb,
SUM (version_store_reserved_page_count)*8 as version_store_kb,
SUM (unallocated_extent_page_count)*8 as freespace_kb,
SUM (mixed_extent_page_count)*8 as mixedextent_kb
FROM sys.dm_db_file_space_usage
if above query shows,
Higher number of user objects then it means that there is more usage of Temp tables , cursors or temp variables
Higher number of internal objects indicates that Query plan is using a lot of database. Ex: sorting, Group by etc.
Higher number of version stores shows Long running transaction or high transaction throughput
You can monitor TempDb via above script and identify the real cause of its growth first. However, 60 GB is quite a small database with 6GB TempDB size is fairly acceptable.
Part of above answer is copied from my other answer from SO.
What does mean abbreviation "TBS" in Oracle database? .
Thanks!
TaBleSpaces
Each table is stored in a segment. Segments are stored in tablespaces. Each segment is allocated in units of "extents" which are allocated in database "blocks".
tablespace -> segment -> extent -> block
You can explicity define tablespaces. You can select which tablespace a table's segment is created in at CREATE TABLE time.
Have a look at
Oracle Concepts - Tablespaces
TBS generally refers to TableSpaces in oracle.....
We have a shell script that perform a physical backup of our oracle database (tar + compress of all our database files). Recently, we created a tablespace containing tables that we dont need to backup its contents.
Is it possible to ignore data files relative to this tablespace and have a valid backup?
PS: we don't want to use RMAN.
I preface my remarks here with a note: this is NOT the normative pattern. Normally, we use RMAN to backup ALL the datafiles in the database. With that said...
Yes, it may be possible to restore and recover the database from a backup with a m ssing datafile. But the recovery will require that the tablespace be dropped when the database is restored.
For the simple case of a dropping a tablespace that contains a single datafile: first restore the database files, then:
STARTUP NOMOUNT;
ALTER DATABASE MOUNT ;
ALTER DATABASE DATAFILE '<complete_path_to_datafile>' OFFLINE DROP ;
ALTER DATABASE OPEN ;
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS ;
Then, continue with database recovery ( RECOVER DATABASE ; )
Obviously, the tablespace_name you provide in the DROP TABLESPACE command would be the one related to the datafile that is dropped.
Obviously, this wouldn't work for the SYSTEM tablespace. And I wouldn't dare try this on other tablespaces like UNDO, SYSAUX, USERS. And there's different syntax for dropping and adding TEMPORARY TABLESPACES.
I don't know of any "gotchas" with the 'DROP TABLESPACE ... INCLUDING CONTENTS', but consider that objects in other tablespaces could be impacted. (Consider that the dropped tablespace might have indexes for tables in other tablespaces, impacts on foreign key constraints, impacts on stored procedures, and so on.)
And it goes without saying, that you would need to test this type of restore procedure in a test environment before you rely on this technique in production.
Without testing, you would be much better served by using RMAN to backup ALL of the datafiles.
NOTE: I have not done anything like this since Oracle 8, possibly Oracle 7.3 (back when we had to roll our own hotbackup scripts). Since we've started using RMAN, I haven't had a need to test anything like this.
NOTE: The RECOVER DATABASE may need to be run before the ALTER DATABASE OPEN. I think you may get an exception warning about "datafile needing more recovery", like you do when you start the database when a tablespace has been left in BEGIN BACKUP mode...