if I have a datafile in a directory and it is getting too big for the directory what command in Oracle can I use to move that file, or do I make another datafile into another directory?
ALTER TABLESPACE
users
ADD DATAFILE
‘/ora01/oracle/oradata/booktst_users_02.dbf’
size 100m
You can do either. Adding a datafile is simpler as it can be done online, with the command you've shown. As long as you don't mind having the datafiles spread across directories, and you don't need to remove the filesystem the file is currently on, this ought to be fine for you.
The documentation explains how to relocate a datafile. I won't quote the whole thing, but essentially, with the tablespace offline, copy the datafile(s) to another disk then update the database control file (and data dictionary) to point to the new location with an ALTER TABLESPACE...RENAME DATAFILE command, then you can bring the tablespace back online.
As the documentation also mentions, make a backup of the modified database. Once the tablespace is using the new copies of the files you can delete the old ones from the filesystem - carefully, make sure you're working on the unused copy! - to free up the disk space.
Another option is to create a new tablespace with its datafile(s) on a larger filesystem and them move all the objects into that, then drop the original. The tablespaces remain online, but access to the objects being moved will be temporarily blocked; if the objects are large that may be a significant issue and much slower than moving the datafiles.
Related
I am using oracle 10g. I have created two schema/user (let's assume produser for production and devuser for development) and allocate same table space let's say "prod" and both schemas/users have some data stored in same tablespace/datafile so here my problem is first, if I drop one schema/user then related tablespace will automatically cleared or not?, if not then how can we reclaim of dropped schema/user tablespace without dropping tablespace/datafile? if you have any please suggest "How"? It will be very helpful.
Thank you!
You can think of a tablespace as being synonymous with a disk partition on your PC. Lets say you bought a 500G disk and partitioned it into 300G for C: drive, and 200G for D: drive.
When you fill your C: drive with files and then delete those files, there is now plenty of room C: drive for new files but only on C: drive. Deleting files on C: drive did not mean you get to use any of that free space for D: drive.
Tablespaces are the same. Space you free up in a tablespace can be reused by other objects (new or otherwise) in that same tablespace.
If you want to give that space that you just freed up to a different tablespace (either an existing one or a new one) then this does not happen automatically. You might be able to do something like
alter database datafile '...' resize <some smaller value>
on the tablespace you just dropped objects from, which would mean it would free up space at the OS level, which would then be allocated to something else (database or otherwise). I say "might" because even if the tablespace is 99% empty, if the remaining objects are located at (say) the beginning AND end of the file, then you can't resize the file smaller than the logical high water mark of space utilised in the file.
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 have a friend who has a website and asked me for help.
I often use MySQL databases but never Oracle databases.
And unfortunately he has an Oracle database, so I can't find a solution.
The available disk space is slowly decreasing... I delete a lot of lines from the table but that doesn't solve his problem.
The database continues to take up disk space slowly.
I read that LOB files do not return disk space, even if you delete data.
How can I reorganize LOB files easily with a simple request?
(or/and) How can I recover disk space on Oracle?
SELECT DISTINCT VERSION FROM PRODUCT_COMPONENT_VERSION
12.1.0.1.0
The BLOB column exists within the table blocks along with data even after deletion. It is only marked as unused. You can use the following command to free up space from the BLOB table:
ALTER TABLE <YOUR_TABLE_NAME> MODIFY
LOB <LOB_COLUMN_NAME>
( SHRINK SPACE );
Now, Table must have released some space and it is now available to be used within the tablespace.
Further, you can just alter the data file and reduce the size of the data file accordingly to free up space from Disk. (Note: Space allocated to the data file will not be automatically reduced. It must be done manually)
Cheers!!
I have created the datafiles in an external hard disk for a particular db . When the hard disk is connected I am able to run the server without any issues . Now when I remove the hard disk and try running the server , it throws error saying
NO DATAFILE PATH Found
This is because the path of datafiles is in the external hard disk .
Now, is there anyway i can run the server against the same database even if the hard disk is not connected ?
Assuming the real question is how to get the external disk datafiles onto the local system, have a look here :
https://docs.oracle.com/cd/B28359_01/server.111/b28310/dfiles005.htm
Outline steps:
Procedure for Renaming Datafiles in a Single Tablespace
To rename datafiles in a single tablespace, complete the following steps:
Take the tablespace that contains the datafiles offline. The database must be open.
For example:
ALTER TABLESPACE users OFFLINE NORMAL;
Rename the datafiles using the operating system - in your case COPY the files from the external disk to local disk
Use the ALTER TABLESPACE statement with the RENAME DATAFILE clause to change the filenames within the database.
For example, the following statement renames the datafiles /u02/oracle/rbdb1/user1.dbf and /u02/oracle/rbdb1/user2.dbf to/u02/oracle/rbdb1/users01.dbf and /u02/oracle/rbdb1/users02.dbf, respectively:
ALTER TABLESPACE users
RENAME DATAFILE '/u02/oracle/rbdb1/user1.dbf',
'/u02/oracle/rbdb1/user2.dbf'
TO '/u02/oracle/rbdb1/users01.dbf',
'/u02/oracle/rbdb1/users02.dbf';
Always provide complete filenames (including their paths) to properly identify the old and new datafiles. In particular, specify the old datafile name exactly as it appears in the DBA_DATA_FILES view of the data dictionary.
Back up the database. After making any structural changes to a database, always perform an immediate and complete backup.
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