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...
Related
I'm new to this Oracle Database. Today I ran DROP TABLE table1; and tried to FLASHBACK it. But the Script Output returned this :
FLASHBACK TABLE TABLE1 TO BEFORE DROP
Error report -
ORA-38305: object not in RECYCLE BIN
38305. 00000 - "object not in RECYCLE BIN"
*Cause: Trying to Flashback Drop an object which is not in RecycleBin.
*Action: Only the objects in RecycleBin can be Flashback Dropped.
I thought that the recyclebin was somehow disabled. So I opened another connection and input this command :
ALTER SESSION SET recyclebin = ON;
and repeated the process again, the result was still the same. There was nothing in the recyclebin when I ran SELECT * FROM RECYCLEBIN;
Did I unintentionally mess up anything ?
The technique you're using is Oracle Flashback Drop. It's enabled when satisfying the following three conditions:
Parameter RECYCLEBIN='on'
Data not being stored in SYSTEM tablespace
Data must be stored in a locally managed tablespace
I guest that you're simulating your examples under SYS user (which has the default tablespace SYSTEM) leading to you can't flachback at all.
I did try to login as SYS user and simulating a small example as yours and do get the same error output as yours.
Try your lab under another user which default tablespace not SYSTEM.
You can verify the conditions by checking:
Recleclebin='on' with SQL*PLUS SQL> SHOW PARAMETER RECYCLEBIN;
Default Tablespace not SYSTEM with SQL> select default_tablespace
from dba_users where username='input_username';
Tablespace datafile is locally managed with SQL>select
extent_management from dba_tablespaces where
tablespace_name='input_tablespace_name';
you didn't mess up anything with the command ALTER SESSION SET recyclebin = ON; but it's late to invoke that command. I think your problem is due your default tablespace to be SYSTEM for tables.
Oracle Flashback Drop reverses the effects of a DROP TABLE operation. It can be used to recover after the accidental drop of a table. Flashback Drop is substantially faster than other recovery mechanisms that can be used in this situation, such as point-in-time recovery, and does not lead to any loss of recent transactions or downtime.
The table and its dependent objects will remain in the recycle bin until they are purged from the recycle bin. You can explicitly purge a table or other object from the recycle bin with the command:
DROP TABLE some_table PURGE;
Dropped objects are kept in the recycle bin until such time as no new extents can be allocated in the tablespace to which the objects belong without growing the tablespace. This condition is referred to as space pressure. Space pressure can also arise due to user quotas defined for a particular tablespace. A tablespace may have free space, but the user may have exhausted his or her quota on it.
When space pressure arises, the database selects objects for automatic purging from the recycle bin. Objects are selected for purging on a first-in, first-out basis, that is, the first objects dropped are the first selected for purging.
There is no fixed amount of space preallocated for the recycle bin. Therefore, there is no guaranteed minimum amount of time during which a dropped object will remain in the recycle bin.
To view only objects in the recycle bin, use the USER_RECYCLEBIN and DBA_RECYCLEBIN views.
I have 2 tablespaces which I want to backup when they are in a consistent state (let's say T0). When problems occur (T1), I want to be able to restore both tablespaces to their state at T0 without recovering all changes that occured between T0 and T1 (I want to ignore them all).
What I could do so far is backing up and recovering tablespaces (with changes that occured after the backup, which is not what I want).
I am using Oracle 11gR2 XE and RMAN.
I am looking for a solution compatible with Oracle 10 g and above.
Thank you for your time and help.
I think the best way to do that is transportable tablespace (http://www.oracle-base.com/articles/misc/transportable-tablespaces.php).
You'll transport your tablespace in an empty database before your operation.
After you have to do a full backup on your new database.
If a problem occur during your migration you could do the inverse operation.
Of course, test this solution before!
What about TABLESPACE POINT IN TIME recovery? Would it suit your needs?
PS: It has some prerequisites like NO FKs into tables in other tablespaces.
And maybe it is not allowed in XE releases.
Does Oracle make use of temp tables during backup procedures?
This has brought up many conversations in the break room, but we are limited in our expertise.
I'm pretty sure, please correct me if i am wrong, but to fully qualify for ACID - you need a way to store the data when the database is taken offline, even for a moment.
SQL Server writes to the transaction log, then will catch up after the DB comes back online - but i am not sure if Oracle follows the same idea.
thank you
If you mean with "Backup" that a Tablespace or the whole database is taken to backup-mode with ALTER TABLESPACE tbname BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP the database is not offline but the tablespace resp. the datafiles on the disk are not written into.
This is necessary to prevent a backup of the datafiles in an inconsistent state (fractured block). The blocks changed (called "dirty") during this process are written to the redo-logfile and applied later when ALTER DATABASE END BACKUP is issued.
Backups done with RMAN (Recovery Manager) dont need backup mode at all.
I have a very large table in my database and I am starting to get this error
Could not allocate a new page for
database 'mydatabase' because of
insufficient disk space in filegroup
'PRIMARY'. Create the necessary space
by dropping objects in the filegroup,
adding additional files to the
filegroup, or setting autogrowth on
for existing files in the filegroup.
How do you fix this error? I don't understand the suggestions there.
If you're using SQL Express you may be hitting the maximum database size limit (or more accurately the filegroup size limit) which is 4GB for versions up to 2005, 10GB for SQL Express 2008 onwards. That size limit excludes the log file.
There isn't really much to add - it pretty much tells you what you need to do in the error message.
Each object (Table, SP, Index etc) you create in SQL is created on a filegroup. The default filegroup is PRIMARY. It is common to create multiple filegroups that span over many disks. For instance you could have a filegroup named INDEXES to store all of your Indexes. Or if you have one very large table you could move this on to a different filegroup.
You can allocate space to a filegroup, say 2GB. If Auto Grow is not enabled once the data in the filegroup reaches 2GB SQL Server cannot create any more objects. This will also occur is the disk that the filegroup resides on runs out of space.
I'm not really sure what else to add - as I said previously, the error message pretty much tells you what is required.
If you are using client tools (MSDE) then the data in the filegroup reaches 2GB, SQL Server cannot create any more objects.
Use DBCC shrinkfile statement to shrink file...
USE databasename ;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE databasename
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (databasename_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE databasename
SET RECOVERY FULL;
GO
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