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
Related
we have a huge DB with daily 20Mil records,
We have an interval partitioned table on creation time column(filled with Sysdate at before insert trigger)
As this data are important and cannot be purged and storage runs out after some time, We have used impdp and expdp to archive old data(we keep few months) and monthly export one partition and import it at archive DB
Disadvantage of this scenario is Dropping exported partition after complete import, Does not completely free the storage, it seems our tablespaces are the problem
Another disadvantage is the data is keep growing and export and import time has reached more than mere hours and it's nearly 2 days, which affects our service quality
Newly we're thinking about using Transportable Tablespaces
I'm not what scenario to use here
Is this right to do this:
daily create a tablespace with a datafile
make new tablespace transportable
alter user and set it's default tablespace to our new one
after some time when data are old, export table using:
expdp transport_tablespaces={our new tablespace}
copy data file from source DB to destination DB
import at destination DB using:
impdp transport_datafiles='/path/to/data/{data file name}.dbf'
if anything went well, drop source partition and free the space
Personally, I'm not sure if my scenario is right, did I understand Transportable Tablespace correctly?
If my scenario is correct, Can you provide a shell-script to automate this to be done
First, there's no such a thing as 'make a tablespace transportable' in Oracle.
You can do what you outline, but, there are some modifications:
As each of your new tablespaces will host a partition, you cannot export it as such, you must exchange the partition with a table, with indexes, ... and then do the export.
you may run into the limit on the number of tablespaces you can create and manage, .... or the number of data files, ...unless you pay attention to what you're doing, ...
on the archive db, you'll have to import the tablespace, then do an exchange partition again. And depending on the number of partitions you need to keep, you may again run into the limit on the number of tablespaces. What you can do is to import the tablespace, do an alter table move to put the data from this tablespace into one that has other partitions, and the drop the imported tablespace.
While creating tables or indexes, I always get the recommendation to add tablespace clause in the queries. Is there any major impact later on our table if we don't use the tablespace clause while creating them ?
This is what I am doing for a very long time.
CREATE TABLE XT_PMB_NOTIFY_UNSUB(
TXNID NUMBER(15),
APP_SEQNO NUMBER(15),
PRIMARY_KEYVAL VARCHAR2(4000) NOT NULL,
OP_CODE VARCHAR2(15),
TXN_STATUS VARCHAR2(1),
CREATE_DT DATE,
PRIMARY KEY (TXNID) );
Recommendation from DBA.
CREATE TABLE XT_PMB_NOTIFY_UNSUB(
TXNID NUMBER(15),
APP_SEQNO NUMBER(15),
PRIMARY_KEYVAL VARCHAR2(4000) NOT NULL,
OP_CODE VARCHAR2(15),
TXN_STATUS VARCHAR2(1),
CREATE_DT DATE,
PRIMARY KEY (TXNID) )
TABLESPACE DATA_ENC_TS;
The answer is it depends on how your company has defined its tablespace rules.
Oracle users (or schemas) can have one "default tablespace" which you can see by querying the database:
select username, default_tablespace from dba_users;
or if you do not have permission for that and you want to know what it is for the current user only:
select username, default_tablespace from user_users;
Or perhaps this one to see all users that are visible to your current connected user:
select username, default_tablespace from user_users;
According to Oracle documentation (https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8003.htm) this is what it means:
Specify the default tablespace for objects that the user creates. If
you omit this clause, then the user's objects are stored in the
database default tablespace. If no default tablespace has been
specified for the database, then the user's objects are stored in the
SYSTEM tablespace.
So for your intents and purposes, when you create a table without explicitly using a tablespace at the end it will go to the user's default tablespace in general. If your DBAs tend to not define a default tablespace then it starts to have more serious impacts, because the table will be stored in a global default tablespace or (heaven forbid) it will go to SYSTEM tablespace. That last option would be extremely detrimental to the database health.
Some companies have the habit of assigning different tablespaces for tables and for indexes for instance. In that case, the users can only have one default tablespace, and if you omit the tablespace clause in the create index (or create table) statement, objects will go to the incorrect tablespace.
Now to the consequences of having a table or index in an incorrect tablespace. A tablespace is a collection of one or more physical operating system files (Oracle refers to them as data files). Whenever you create a table or index in a tablespace oracle allocates space in that datafile, which Oracle calls segments. Segments are logical units inside a data file. Keep in mind Oracle further breaks down segments into smaller logical units called extents and blocks, but that is a bit beyond the topic here. If you are interested there is more to read here: https://docs.oracle.com/cd/B19306_01/server.102/b14220/logical.htm
Let's go back to segments. Segments exist inside datafiles that belong to tablespaces. When you put your object in a tablespace and you want to move it out to a different tablespace, Oracle needs to physically write to files on the OS. And that can be simple if the table is empty, or can be a fair amount of work if it concerns a massive table spanning multiple datafiles or containing gigabytes or terabytes of data. It may mean an application outage is required to fix it.
Oracle provides certain methods to avoid application outages in those scenarios, like for example Online Redefinition (package DBMS_REDEFINITION). But I would hope we can agree that their use can be better leveraged for application migrations and things of the sort.
Using default tablespace settings is fine in many cases, by all means, but if you will allow me perhaps, the rule of thumb for many things Oracle is if you can write code to do something explicitly instead of relying on default values, do yourself and your DBA the favor. In general, the flexibility of relying on it is trumped by even a couple times of facing yourself with a surprise and then being responsible for cleaning it up later.
If you don't specify a tablespace, Oracle will use the default tablespaces assigned to the schema. You can find your default tablespace with the query below. Unless you have a very small development database w/o many schemas, that may be OK, but otherwise it is good practice to explicitly define them.
select *
from database_properties
where property_name like 'DEFAULT%TABLESPACE';
PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
------------------------------ -------------------- ----------------------------------------
DEFAULT_TEMP_TABLESPACE TEMP Name of default temporary tablespace
DEFAULT_PERMANENT_TABLESPACE USERS Name of default permanent tablespace
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.
My program creates a database schema. The queries related to tables and/or view creations work just fine but the first insert I do fails with
unable to create INITIAL extent for segment in tablespace SYSAUX
error. It is a straightforward insert in a table that has just two columns, one two strings.
The user is obviously not set to use SYSAUX tablespace and has one on its own so:
I don't understand where a SYSAUX-related failure can come from?
How to fix this?
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?