Restore tablespace USERS doesn't work. Oracle backup - oracle

I created a schema and my_table_test;
ALTER SESSION SET CURRENT_SCHEMA=c##wojtek_admin;
CREATE TABLE my_table_test
( id_test INT
);
Then I created a backup using: BACKUP TABLESPACE USERS FORMAT 'c:\FRA\users%u';
Then I dropped my_table_test and run below commands:
RMAN> RUN{
2> SQL 'ALTER TABLESPACE USERS OFFLINE';
3> RESTORE TABLESPACE USERS;
4> RECOVER TABLESPACE USERS;
5> SQL 'ALTER TABLESPACE USERS ONLINE';
6> }
Why my_table_test is dropped after I restored USERS TABLESPACE?

In a multitenant database you will have several 'USERS' tablespaces. One at the CDB level and one for each PDB.
RMAN> report schema;
Report of database schema for database with db_unique_name T101N
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 960 SYSTEM YES +DATAC4/T101N/DATAFILE/system.500.1057688607
3 620 SYSAUX NO +DATAC4/T101N/DATAFILE/sysaux.498.1057688643
4 840 UNDOTBS1 YES +DATAC4/T101N/DATAFILE/undotbs1.587.1057688657
5 310 PDB$SEED:SYSTEM NO +DATAC4/T101N/86B637B62FE07A65E053F706E80A27CA/DATAFILE/system.482.1057689319
6 380 PDB$SEED:SYSAUX NO +DATAC4/T101N/86B637B62FE07A65E053F706E80A27CA/DATAFILE/sysaux.503.1057689319
7 5 USERS NO +DATAC4/T101N/DATAFILE/users.499.1057688659
8 190 PDB$SEED:UNDOTBS1 NO +DATAC4/T101N/86B637B62FE07A65E053F706E80A27CA/DATAFILE/undotbs1.489.1057689319
9 310 PDB1:SYSTEM YES +DATAC4/T101N/B52F60948095635FE053B506330A63CA/DATAFILE/system.405.1057690077
10 390 PDB1:SYSAUX NO +DATAC4/T101N/B52F60948095635FE053B506330A63CA/DATAFILE/sysaux.501.1057690077
11 195 PDB1:UNDOTBS1 YES +DATAC4/T101N/B52F60948095635FE053B506330A63CA/DATAFILE/undotbs1.497.1057690077
12 5 PDB1:USERS NO +DATAC4/T101N/B52F60948095635FE053B506330A63CA/DATAFILE/users.566.1057690091
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 67 TEMP 32767 +DATAC4/T101N/TEMPFILE/temp.573.1057688719
2 43 PDB$SEED:TEMP 32767 +DATAC4/T101N/B52F34797E9D6750E053B506330AE7C0/TEMPFILE/temp.481.1057689337
3 43 PDB1:TEMP 32767 +DATAC4/T101N/B52F60948095635FE053B506330A63CA/TEMPFILE/temp.496.1057690079
Note! RMAN's best feature. RMAN can actually tell you what to do in different scenarios.
# data recovery advisor (DRA)
list failure all;
advise failure;
repair failure preview;
repair failure;

First, it's important to note that it looks like you're using a Multitenant Database but you've decided to put user data inside the root container, this is generally a bad idea - you should be using a Pluggable Database for pretty much everything (this will also mean you don't need to prefix your usernames with C##.
Your restore and recover statements will recover the tablespace up until now. If you want to recover it to before you dropped the tablespace then Oracle will also need to do some work on the system tablespace (for the data dictionary) - but you don't only want to restore and recover your USERS tablespace. You'd need to restore your backup somewhere else, recover it to the desired point, then take the USERS tablespace and put it back into your original database.
This is simply referred to as Tablespace Point In Time Recovery, Oracle has helpfully done all the hard scripting work for you, but you should read what's going on https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmtspit.htm#BRADV89790
RECOVER TABLESPACE users
UNTIL ?
AUXILIARY DESTINATION '?';
(Once you've read the docs you'll see how to fill this out).
There is also the ability to do this easily at a table level, so if you want to only recover that dropped table and not revert everything else in that tablespace, you could:
RECOVER TABLE c##wojtek_admin.my_table_test
UNTIL ?
AUXILIARY DESTINATION '?' ;
See https://oracle-base.com/articles/12c/rman-table-point-in-time-recovery-12cr1 for further details.

Related

Recovering an Oracle tablespace (APEX) from file system backups of database tablespace files

I'm trying to recover the applications of an Oracle APEX workspace deleted accidentally. The database is 12c and APEX 18.1
What would be the best way to go about it, if the only backup available is an OS level backup of the oradata folder (with all Tablespace files) ?. My APEX schema lives on its own tablespace. Can I simply copy over last night's copy of the APEX table space file over the current one to restore ?
There are no RMAN backups, and the database is installed with all default options, no archive log and no flashback. I also don't have any dump produced with expdp.
I've already tried to use the dbms_flashback package to go back a few hours but to no avail, as I get an error about rollback segment too small. The earliest I can make it work, is already at a state after the desired recovery point.
Clarification
I am assuming you only lost the APEX tablespace but your database is currently functioning. If this is the case, and assuming your APEX tablespace does not span multiple datafiles, you can attempt to swap out the datafile. Please force a backup in rman before trying any of this.
There are a few different options here. All you really need are the following
Datafile
Control file
Archive / redologs (if you want to move forward or backward in time)
I'm going to outline two options because I don't have all the pertinent information. The first option attempts to actually restore the datafiles through rman, the second one simply swaps it out. The first is obviously preferential but may not be achievable.
RMAN Restore
First set the following parameter in your init.ora file
_allow_resetlogs_corruption=TRUE
Move your entire oradata backup directory to /tmp/oradata. Locate then location of your dbf and ctl files in that directory.
Then run rman target / from bash terminal. In rman run the following.
RESTORE CONTROLFILE FROM '/tmp/oradata/your_ctrl_file_dir'
ALTER TABLESPACE apex OFFLINE IMMEDIATE';
SET NEWNAME FOR DATAFILE '/tmp/oradata/apex01.dbf' TO
RESTORE TABLESPACE apex;
SWITCH DATAFILE ALL;
RECOVER TABLESPACE apex;
Swap out Datafile
First find the location of your datafiles. You can find them by running the following in sqlplus / as sysdba or whatever client you use
spool '/tmp/spool.out'
select value from v$parameter where name = 'db_create_file_dest';
select tablespace name from dba_data_files;
View the spool.out file and
Verify the location of your datafiles
See if the datafile still is associated with that tablespace.
If the tablespace is still there run
select file_name, status from dba_data_files WHERE tablespace name = < name >
You want your your datafile to be available. Then you want to set the tablespace to read only and take it offline
alter tablespace < name > read only;
alter tablespace < name > offline;
Now copy your dbf file the directory returned from querying db_create_file_dest value. Don't overwrite the old one, then run.
alter tablespace < name > rename datafile '/u03/waterver/oradata/yourold.dbf' to '/u03/waterver/oradata/yournew.dbf'
This updates your controlfile to point to the new datafile.
You can then bring your tablespace back online and back in read write mode. You may also want to verify the status of the tablespace status, the name of the datafile associated with that tablespace, etc.

persistent error - unable to extend temp segment by 128 in tablespace TEMP

I was given a query that's running out of space in the TEMP tablespace. (see error-message below) As a quick solution to get the user back up and running, I simply added a TEMPFILE to the tablespace. (see alter statement below) But, when I ran the query again, it still ran out of space. I can see from querying dba_temp_files that the tablespace is pretty big, and it does contain both datafiles, but I thought the MAXSIZE UNLIMITED clause would have solved my problem by not allowing the new datafile to run out of space.
Besides rewriting the query, what would you recommend?
Thanks!
Dave
SQL Error: ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
01652. 00000 - "unable to extend temp segment by %s in tablespace %s"
*Cause: Failed to allocate an extent of the required number of blocks for
a temporary segment in the tablespace indicated.
*Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more
files to the tablespace indicated.
ALTER TABLESPACE temp
ADD TEMPFILE '+DATAC1/cop3/tempfile/temp01.dbf' SIZE 10g
AUTOEXTEND ON
NEXT 1g
MAXSIZE UNLIMITED;
SQL> SELECT substr(tablespace_name,1,4) as tbls,
2 substr(file_name,1,40) as file_name,
3 bytes/1000000000 as gigabytes
4 FROM dba_temp_files
5 WHERE tablespace_name = 'TEMP'
6 ;
TBLS FILE_NAME GIGABYTES
---- ---------------------------------------- ----------
TEMP +DATAC1/cop3/tempfile/temp.771.915115045 21.4748365
TEMP +DATAC1/cop3/tempfile/temp01.dbf 34.359722

ORA-01652 - Query doen't work with hibernate but it works fine in SQL client

I execute a SQL query with hibernate and the application give the error:
ORA-01652: unable to extend temp segment
The TABLE SPACE has 4 GB.
The strange thing is that the query from the application yesterday was working fine, and today it doen't work.
I have not made any changes either in the database or application.
The oracle version is Oracle 11g
You are running short on space in temp tablespace , use this query t check how much space you have in your temp tablespace
SQL> select file_name,SUM(bytes)/1024/1024 "Current_size_mb", sum(maxbytes)/1024/1024 "max_size_mb" from dba_temp_files group by file_name;
FILE_NAME Current_size_mb max_size_mb
---------------------------------------------------------------------- --------------- -----------
C:\AKS\AKDB\ORADATA\RESEARCH\TEMP01.DBF 20 32767.9844
Adding a new tempfile to temp tablespace
SQL> alter tablespace temp add tempfile 'C:\AKS\AKDB\ORADATA\RESEARCH\TEMP02.DBF' size 100m autoextend on maxsize 1g;
Temporary tablespace called TEMP which is used internally by database for operations like distinct, joins,etc to fetch large amount of data.
So, after increasing the size of TEMP tablespace the issue can be resolved.
Follow this link : How to shrink temp tablespace in oracle?

how to move undo datafile in running database without disturbing transactions?

Unfortunately one UNDO data file was misplaced in wrong location when I was adding space. I want to move that file to correct location. As it is Production database, I don't want to disturb the ongoing transactions. Can I offline that particular undo data file, while moving... will Database work normally with zero data loss?
Version Of Oracle DB: 11.2.0.4.0
can any one suggest?
During database running and in 24/7 environment, you should need to create new undo tablespace with new location of undo datafile. After creating this newer tablespace, you can switch older to newer undo tablespace online without affecting any ongoing transactions.
Following example shows how to achieve your goal. Using this trick, you can avoid data loss.
SQL>create undo tablespace undotbs2 datafile '/yournewlocation/undotbs02.dbf' size 1000m;
Now set new undo tablespace as default undo tablespace using following command as SYSDBA in SQLPLUS
SQL> alter system set undo_tablespace= undotbs2 ;
After finishing above task you can drop old undotbs tablespace from database using following command.
SQL> drop tablespace undotbs including contents;
I would consider creating the undo tablespace as a BIGFILE datafile:
CREATE BIGFILE UNDO TABLESPACE UNDOTBS02
DATAFILE '/yournewlocation/UNDOTBS02.dbf'
SIZE 100M AUTOEXTEND ON NEXT 100M
MAXSIZE 500G; --or whatever size you consider sufficient for your DB
I would also alter the system with a scope of BOTH, to make sure the change is made in both memory and spfile:
ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS02 SCOPE=BOTH;
Then, provided all active transactions and the UNDO_RETENTION period (if any) are done, you'll be able to drop the tablespace as described by doc123.

How to shrink temp tablespace in oracle?

How can we shrink temp tablespace in oracle? And why it is increasing so much like upto 25 GB since there is only one schema in the database for the application and data table space size is 2 GB and index table space size is 1 GB used.
Oh My Goodness! Look at the size of my temporary table space!
Or... how to shrink temporary tablespaces in Oracle.
Yes I ran a query to see how big my temporary tablespace is:
SQL> SELECT tablespace_name, file_name, bytes
2 FROM dba_temp_files WHERE tablespace_name like 'TEMP%';
TABLESPACE_NAME FILE_NAME BYTES
----------------- -------------------------------- --------------
TEMP /the/full/path/to/temp01.dbf 13,917,200,000
The first question you have to ask is why the temporary tablespace is so large.
You may know the answer to this off the top of your head. It may be due to a
large query that you just run with a sort that was a mistake (I have done that
more than once.) It may be due to some other exceptional circumstance. If that
is the case then all you need to do to clean up is to shrink the temporary
tablespace and move on in life.
But what if you don't know? Before you decide to shrink you may need to do some
investigation into the causes of the large tablespace. If this happens on a
regular basis then it is possible that your database just needs that much space.
The dynamic performance view
V$TEMPSEG_USAGE
can be very useful in determining the cause.
Maybe you just don't care about the cause and you just need to shrink it.
This is your third day on the job. The data in the database is only 200MiB
if data and the temporary tablespace is 13GiB - Just shrink it and move on.
If it grows again then we will look into the cause. In the mean time I am
out of space on that disk volume and I just need the space back.
Let's take a look at shrinking it. It will depend a little on what version
of Oracle you are running and how the temporary tablespace was set up.
Oracle will do it's best to keep you from making any horrendous mistakes
so we will just try the commands and if they don't work we will shrink
in a new way.
First let's try to shrink the datafile. If we can do that then we get back
the space and we can worry about why it grew tomorrow.
SQL>
SQL> alter database tempfile '/the/full/path/to/temp01.dbf' resize 256M;
alter database tempfile '/the/full/path/to/temp01.dbf' resize 256M
*
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value
Depending on the error message you may want to try this with different sizes
that are smaller than the current site of the file. I have had limited
success with this. Oracle will only shrink the file if the temporary tablespace
is at the head of the file and if it is smaller than the size you
specify. Some old Oracle documentation (they corrected this) said that
you could issue the command and the error message would tell you what
size you could shrink to. By the time I started working as a DBA this was
not true. You just had to guess and re-run the command a bunch of times
and see if it worked.
Alright. That didn't work. How about this.
SQL> alter tablespace YOUR_TEMP_TABLESPACE_NAME shrink space keep 256M;
If you are in 11g (Maybee in 10g too) this is it! If it works you may want
to go back to the previous command and give it some more tries.
But what if that fails. If the temporary tablespace is the default temporary
that was set up when the database was installed then you may need to do a
lot more work. At this point I usually re-evaluate if I really need that
space back. After all disk space only costs $X.XX a GiB. Usually I don't want
to make changes like this during production hours. That means working at 2AM
AGAIN! (Not that I really object
to working at 2AM - it is just that... Well I like to sleep too. And my wife
likes to have me at home at 2AM... not roaming the downtown streets at 4AM trying
to remember where I parked my car 3 hours earlier. I have heard of that "telecommuting"
thing. I just worry that I will get half way through and then my internet connectivity
will fail - then I have to rush downtown to fix it all before folks show up in the
morning to use the database.)
Ok... Back to the serious stuff...
If the temporary tablespace you want to shrink is your default
temporary tablespace, you will have to first create a new temporary
tablespace, set it as the default temporary tablespace then drop
your old default temporary tablespace and recreate it. Afterwords
drop the second temporary table created.
SQL> CREATE TEMPORARY TABLESPACE temp2
2 TEMPFILE '/the/full/path/to/temp2_01.dbf' SIZE 5M REUSE
3 AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Tablespace created.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;
Database altered.
SQL> DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
SQL> CREATE TEMPORARY TABLESPACE temp
2 TEMPFILE '/the/full/path/to/temp01.dbf' SIZE 256M REUSE
3 AUTOEXTEND ON NEXT 128M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Tablespace created.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
Database altered.
SQL> DROP TABLESPACE temp2 INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
Hopefully one of these things will help!
The options for managing tablespaces have got a lot better over the versions starting with 8i. This is especially true if you are using the appropriate types of file for a temporary tablespace (i.e. locally managed tempfiles).
So, it could be as simple as this command, which will shrink your tablespace to 128 meg...
alter tablespace <your_temp_ts> shrink space keep 128M;
The Oracle online documentation is pretty good. Find out more.
edit
It would appear the OP has an earlier version of the database. With earlier versions we have to resize individual datafiles. So, first of all, find the file names. One or other of these queries should do it...
select file_name from dba_data_files where tablespace_name = '<your_temp_ts>'
/
select file_name from dba_temp_files where tablespace_name = '<your_temp_ts>'
/
Then use that path in this command:
alter database datafile '/full/file/path/temp01.dbf' resize 128m
/
You should have written what version of Oracle you use. You most likely use something else than Oracle 11g, that's why you can't shrink a temp tablespace.
Alternatives:
1) alter database tempfile '[your_file]' resize 128M; which will probably fail
2) Drop and recreate the tablespace. If the temporary tablespace you want to shrink is your default temporary tablespace, you may have to first create a new temporary tablespace, set it as the default temporary tablespace then drop your old default temporary tablespace and recreate it. Afterwards drop the second temporary table created.
3) For Oracle 9i and higher you could just drop the tempfile(s) and add a new one(s)
Everything is described here in great detail.
See this link: http://databaseguide.blogspot.com/2008/06/resizing-temporary-tablespace.html
It was already linked, but maybe you missed it, so here it is again.
It will be increasing because you have a need for temporary storage space, possibly due to a cartesian product or a large sort operation.
The dynamic performance view V$TEMPSEG_USAGE will help diagnose the cause.
Temporary tablespaces are used for database sorting and joining operations and for storing global temporary tables. It may grow in size over a period of time and thus either we need to recreate temporary tablespace or shrink it to release the unused space.
Steps to shrink TEMP Tablespace
alter database datafile 'C:\ORA_SERVER\ORADATA\AXAPTA\AX_DATA.ORA' resize 40M;
If it doesn't help:
Create new tablespace
Switch to new temporary tablespace
Wait until old tablespace will not be used
Delete old tablespace
I don't bother with dropping the alternate temp in case i need to reclaim storage again in the future...
from temp group set default to stand-alone temp
wait awhile, then resize members of temp group
set default back to temp group
wait awhile, resize stand alone temp. there's no rush to do the last step

Resources