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.
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'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.
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.