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.
Related
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.
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...
I have question regarding sql system database that what purpose of these database of msdb and msdb.
Thanks in advance.
Check MSdn : System Databases and Data : http://msdn.microsoft.com/en-us/library/aa174522%28v=sql.80%29.aspx
Microsoft® SQL Server™ 2000 systems have four system databases:
* master
The master database records all of the system level information for a SQL Server system. It records all login accounts and all system configuration settings. master is the database that records the existence of all other databases, including the location of the database files. master records the initialization information for SQL Server; always have a recent backup of master available.
* tempdb
tempdb holds all temporary tables and temporary stored procedures. It also fills any other temporary storage needs such as work tables generated by SQL Server. tempdb is a global resource; the temporary tables and stored procedures for all users connected to the system are stored there. tempdb is re-created every time SQL Server is started so the system starts with a clean copy of the database. Because temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down, there is never anything in tempdb to be saved from one session of SQL Server to another.
By default, tempdb autogrows as needed while SQL Server is running. Unlike other databases, however, it is reset to its initial size each time the database engine is started. If the size defined for tempdb is small, part of your system processing load may be taken up with autogrowing tempdb to the size needed to support your workload each time to restart SQL Server. You can avoid this overhead by using ALTER DATABASE to increase the size of tempdb.
* model
The model database is used as the template for all databases created on a system. When a CREATE DATABASE statement is issued, the first part of the database is created by copying in the contents of the model database, then the remainder of the new database is filled with empty pages. Because tempdb is created every time SQL Server is started, the model database must always exist on a SQL Server system.
* msdb
The msdb database is used by SQL Server Agent for scheduling alerts and jobs, and recording operators.
In Sqlsever Enterprise manager, there are some default databases are provided like tempdb and etc. What is significance of those databases?
TempDB is used for temporary work in SQL Server. Anytime you create a temp table that storage is done inside of TempDB. Here is a very good article from MSDN
Here are some points referenced from the MSDN:
The tempdb system database is a global resource that is available to all users connected to the instance of SQL Server and is used to hold the following:
•Temporary user objects that are explicitly created, such as: global or local temporary tables, temporary stored procedures, table variables, or cursors.
•Internal objects that are created by the SQL Server Database Engine, for example, work tables to store intermediate results for spools or sorting.
•Row versions that are generated by data modification transactions in a database that uses read-committed using row versioning isolation or snapshot isolation transactions.
•Row versions that are generated by data modification transactions for features, such as: online index operations, Multiple Active Result Sets (MARS), and AFTER triggers.
Operations within tempdb are minimally logged. This enables transactions to be rolled back. tempdb is re-created every time SQL Server is started so that the system always starts with a clean copy of the database. Temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down. Therefore, there is never anything in tempdb to be saved from one session of SQL Server to another. Backup and restore operations are not allowed on tempdb.
There is also the master database (holds information about all databases), Model database, MSDB (stores information on the sql agent, dts, jobs, etc).
More info here as well
MASTER - This keeps all server-level information, and meta-data about all databases on the server. Don't lose this :)
MSDB - Holds information about SQL Agent jobs and job run history
TEMPDB - Used as a temporary "work space" for temporary tables and lots of other stuff (like sorting and grouping)
MODEL - When you create a new, blank database, it makes a copy of MODEL as a template
DISTRIBUTION - (You will only see this on servers where you have set up replication) Holds records pending for replication.
SQL Server uses tempdb to store internal objects such as the intermediate results of a query. You can get more details here.
I am trying to understand the tempDB and following are the doubts popping in my mind.
What is the lifetime of data in tempDB? Say a query is doing some Order By and uses tempDB for performing that. After this query finishes, someone else also executes a query which utilizes the tempDB. Will the second query find records written by first query in the tempDB or will they be deleted?
Are there any visible tables created inside the tempDB by the Sql Engine? How can I know which temporary table is created because of this query? Is there any naming convention followed by the Sql engine for naming these temporary tables?
I am new to tempDB so please pardon me for asking such silly (if at all) questions :-)
It will be very nice if someone can point me to a good resource which can help me learn about tempDB.
Temp table is stored in tempdb until the connection is dropped (or in the case of a global temp tables when the last connection using it is dropped). You can also (and it is a good practice to do so) manually drop the table when you are finished using it with a drop table statement.
No, others cannot see your temp tables if they are local temp tables (They can see and use global temp tables) Multiple people can run commands which use the same temp table name but they will not be overlapping in a local temp table and so you can have a table named #test and so can 10,000 other users, but each one has its own structure and data.
You don't want to generally look up temp tables in tempdb. It is possible to check for existence, but that is the only time I have ever referenced tempdb directly. Simply use your temp table name. Example below of checking for existence
IF OBJECT_ID('TempDB.dbo.#DuplicateAssignments') IS NOT NULL
BEGIN
DROP TABLE #DuplicateAssignments
END
You name temp tables by prefacing the name with # (for local tables the ones you would use 999.9% of the time) and ## for global temp tables, then the rest of the name you want.
There's a few MSDN articles that are probably the best source of information on the tempDB database in SQL Server.
tempdb Database
The tempdb system database is a global
resource that is available to all
users connected to the instance of SQL
Server and is used to hold the
following:
Temporary user objects that are explicitly created, such as: global or
local temporary tables, temporary
stored procedures, table variables, or
cursors.
Internal objects that are created by the SQL Server Database Engine, for
example, work tables to store
intermediate results for spools or
sorting.
Row versions that are generated by data modification transactions in a
database that uses read-committed
using row versioning isolation or
snapshot isolation transactions.
Row versions that are generated by data modification transactions for
features, such as: online index
operations, Multiple Active Result
Sets (MARS), and AFTER triggers.
Operations within tempdb are minimally
logged. This enables transactions to
be rolled back. tempdb is re-created
every time SQL Server is started so
that the system always starts with a
clean copy of the database. Temporary
tables and stored procedures are
dropped automatically on disconnect,
and no connections are active when the
system is shut down. Therefore, there
is never anything in tempdb to be
saved from one session of SQL Server
to another. Backup and restore
operations are not allowed on tempdb.
There's also tempdb and Index Creation, this blog post along with Working with tempdb in SQL Server 2005 which states:
The SQL Server system database, tempdb, has undergone a number of changes in SQL Server 2005. There are new tempdb usages and internal optimizations in SQL Server 2005; tempdb architecture is mostly unchanged since SQL Server 2000.
The tempdb system database is very similar to a user database. The main difference is that data in tempdb does not persist after SQL Server shuts down.
The temporary tables created in TempDB are dropped when the query is completed.
I'm not sure on this (I would have to try it), but I think theoretically ALL tables created in TempDB are visible, although only the user that created the table has permission to access it.