Given that
there is a single tablespace pointing to one file, and there are many schemas pointing to that tablespace and there are many simultaneous jobs doing heavy DDL operations (dropping database, dropping indexes, creating a large database from scratch with data import) using these schemas,
is it possible the tablespace somehow locked so that there would be timeouts for some jobs using these schemas?
Related
On Oracle 12c, is the content of each datafile belonging to a single tablespace the same?
If yes, is it because of performance or backup purpose thus recommanding us to store each datafile on different drives?
If no then why would we create multiple datafiles for a single tablespace when we can autoextend each datafile?
No.
The idea of multiple datafiles supporting a single tablespaces is to be able to use striping. This ofcourse only makes sense if your server has multiple physical storage devices that preferably also have their own io interface.
À table will be in the tablespaces and can allocate space in all available datafiles. So the table data can be in all datafiles.
If your io system does not consist of multiple physical devices you might as well use a bigfile tablespace that just has one big datafile. In older releases this was a restore nightmare because the backup and restore was performed file by file.
I am using two tablespaces from the same Oracle database (11g), one is tablespace A, the other is B.
I'd like to set a daily planified task which would alter the tablespace B in order to integrate the changes made to the tablespace A during the day (example: new tables, new columns, triggers or relations).
Has anyone an idea on how to set up such task ?
Thank you very much for your anwers and have a nice day
i have to take incremental backup of 5 specific tables in a oracle database...i cannot use data pump api as it doesn't support incremental backup...in recovery manager(RMAN) the backup is taken of whole database but i want to have backup if data changes in these 5 specific tables , not all tables in which data changes
You can take incremental backups of databases, individual tablespaces or datafiles. So if you only want 5 tables, you could move those tables into their own tablespace and then take backups of just that tablespace.
You would want to be very sure that these tables are "self-contained" in the sense that if you wanted to restore that tablespace to a specific point in time, you would not introduce a logical corruption into the rest of the database.
In Oracle schema used size can be greater than tablespace used size ? If yes how its possible as schema is associated with tablespace ?
A schema is not "associated" with a tablespace.
A user (=schema) can have a default tablespace, but that does not necessarily mean that all tables that user owns are stored in that default tablespace. If the user has the privileges, tables can be created in other tablespaces as well.
In addition to what #a_horse_with_no_name mentioned, you need to undrstand few basics of orale as well.
Oracle Tablespace -
This is a logical structure, meaning that a tablespace is not a
physical object
A tablespace is made of 1 or more physical structures called
datafiles. A datafile is a physical file on disk, just like any other file which sits on a hard disk but in an Oracle format. The datafile is created as part of a tablespace, and only one tablespace
Each tablespace can have different characteristics, such as extent
size and how the extents are managed
They are used to group segments into logical
groups. For example, you may have accounting data in one tablespace
and reporting data in another.
The Oracle Schema or User
Oracle Schema and user are synonymous and the terms are usually used
interchangeably
There can be thousands of users within one database
The schema owns segments and objects (tables, indexes,views,
constraints, etc) and each segment/object can belong to only one
schema
I have an Oracle table that is in it's own tablespace. It has a spatial index in another tablespace and a normal index in another. If I want to drop them all. Does it matter what order I proceed in?
Drop the table. The indexes will be dropped along with the table.
Indexes are optional structures associated with tables and clusters. If you drop the table, the associated indexes are also dropped.
To answer your confusion about different tablespaces, there is a reason to create in different tablespace or within same tablespace as that of the table. Keeping them in same tablespace makes it easy for database maintenance, however, keeping in different tablespaces is better in terms of performance.
From documentation -
Indexes can be created in any tablespace. An index can be created in
the same or different tablespace as the table it indexes. If you use
the same tablespace for a table and its index, it can be more
convenient to perform database maintenance (such as tablespace or file
backup) or to ensure application availability. All the related data is
always online together.
Using different tablespaces (on different disks) for a table and its
index produces better performance than storing the table and index in
the same tablespace. Disk contention is reduced. But, if you use
different tablespaces for a table and its index and one tablespace is
offline (containing either data or index), then the statements
referencing that table are not guaranteed to work.