I have a database in SQL Server that I plan to migrate to Oracle but I want to know how the Tablespace configuration should be, I have investigated but I still have some doubts about how to implement it, my database in SQL Server has 3 filegroups pointing to disks different, it is 500gb, how would you recommend that I create the tablespace in Oracle?
Tablespace implementation will depend somewhat on your data and your physical storage devices. While not strictly necessary (especially with Oracle 19c) a lot of people separate data and indexes into separate tablespaces, and sometimes LOBs too. If you're working with local disk drives on a physical server, then you probably want to separate the index tablespace and the data tablespace onto different disks or LVM volumes. If you are using Oracle ASM for storage, then physical separation is handled automatically. The number of files will be up to you, with max file size being OS-dependent. For many operating systems 32GB is the max file size for an individual data file, but you can add many files to each tablespace.
Related
How or what ways I would need to store an amount of data that is larger than machine memory into database (Ex. data is 20 GB, RAM is 16 GB). Considering I am using one machine, and all the data is document oriented (NoSQL)
The most easy solution is to use wiredtiger. It's an embedded key-value store with ACID guarantees. It's unlike REDIS.
What potential problems can occur in Oracle DB, when using too large temporary table space, except as unreasonably large consumption of disk space?
A large temporary tablespace will not cause any performance issues. I've tuned SQL on databases with more than a terabyte of temporary tablespace and never seen any issues caused by that space.
When we have created some indexes as part of performance tuning,
CREATE INDEX index_emp ON emp(eid);
The index created in a default tablespace say myTS_D1. When I checked, some of the indexes are having their tablespace value
myTs_I1. And I understood that we should specify the tablespace name at the time of creating the index.
What is the impact ? Is this creates any issue, since some of them are in one tablespace and others in a different one.
The idea of having separate tablespaces is that you can put them on separate physical disks.
Maybe you have a fast SSD that you want to use for some frequently accessed indexes for example. Or maybe you want to distribute disk I/O across multiple controllers to maximize throughput.
Aside from any performance or operational impact this tablespace placement has, there is no difference. For a database user (who only sees the logical schema) it looks the same.
Using separate tablespaces for indexes and data does not improve performance, it only creates more complexity which leads to more problems later. The more tablespaces and datafiles your DBAs have to manage the more likely something will go wrong.
Oracle has the concept of a tablespace. Does a tablespace resemble actual physical storage space on the disk? If this is true, and I delete a million records from the database, will the space on the disk be freed up immediately?
No and no.
A tablespace is made using one or more datafiles. A datafile comes closest to a disk. The data in a tablespace is striped over the datafiles. If you delete rows from a table, there will be free space in that table. If you then shrink that table, the free space in the tablespace grows and the same in the supporting tablespaces.
If you are lucky and your table data was in the end of the datafile[s], you might be able to also shrink the datafile, after which you end up with more free space on the OS.
Yes a tablespace represents actual physical storage space on the disks.
No, if you delete a million records then no space will be freed.
A tablespace is a collection of datafiles on the disk that are pre-sized; by removing data from one of these datafiles you don't free up any space because you haven't reduced the size of the tablespace. It has a predetermined size that has not changed.
You can manually resize a datafile but only if the amount of data stored in that file (not the tablespace) is less than the size you want to reduce it to. To use Oracle's example syntax:
ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf'
RESIZE 100M;
This is not something to be playing around with. There are often good reasons for the size of datafiles and tablespaces. You should talk to your DBA before doing anything.
The tablespace in Oracle 10g is almost 100% used.
Size (MB) = 571,768.0
Used (MB) = 571,534.0
I just deleted (and committed) thousands of records in a table that belongs to a schema associated with that tablespace. Surprisingly, no space was freed up according to the Tablespaces page on Enterprise Manager.
Question: is there anything that I need to do to force Oracle to release the space corresponding to the deleted records?
The space you are seeing is for SEGMENTS on tablespace.
A Tablespace contains Segments. Each Segment is associated to an Index or a Table. Segments contains extends, and extends contains blocks. An for a table, a block contains rows.
When you delete rows on a table you are freeing the space ocuppied by rows but the space for new segments remains equal.
To free this space you can try to:
ALTER TABLESPACE xxx COALESCE;
or
ALTER TABLE xxx MOVE;
The first one, will "combine all contiguous free extents into larger contiguous extents". Depending on your configuracion, this can be executed by Oracle automatically. Also, may be it does not free to much because the location of data relative to the highwatermark on segment.
The second one "lets you relocate data of a nonpartitioned table or of a partition of a partitioned table into a new segment, optionally in a different tablespace, and optionally modify any of its storage attributes.". Be carefull with this because you need free space to achieve this, execute it against another tablespace or add more datafiles.
If you are using oracle 10g or greater, you can purge the recycle bin using command
purge recylebin
or even purge the contents related to the tablespace using
purge tablespace
This should free up the space which is deleted but not yet available , please note this would be made available automatically when the space stress occurs for the given tablespace.
In addition,
You can use the segment advisor to find all the segments that you can "shrink", and easily reclaim your space.
Read more at
Segment Shrink
And the last one you can use with locally managed tablespaces
Alter Tablespace tablespace_name shrink space
This would free as much space as possible while maintaining other attributes.
Rebuild your indexes.