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.
Related
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.
Recently my oracle datafiles are getting scarce,
so that I've added large size of datafiles to table space.
Then, some index became unused out of sudden...
And the program-performance got worse.
Does anybody know such case that Adding datafile affect index-usage?
No. Data file operations and index operations are completely separate. Likely the two occurrences are coincidental, but unrelated.
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.
Is it a best practice to keep composite unique indexes on fact tables in a Oracle EDW - data mart for avoiding duplicates? will it impact ETL data load performance? Please provide your thoughts on this topic. What are other alternative ways to gain SLA for ETL load?
Each insert into a table that has an index will cause that index to be updated causing IO and slowing it down a bit. So loading into a table with indexes whether unique or not will be a bit slower. You can drop that index, load and then create it again. It will reduce index fragmentation and usually will be faster with large loads.
I'm surprised to see a unique index on a fact table. Usually there is not so much uniqueness required there and in general data warehouses denormalize and duplicate data.
It all depends on your case. If you can use ETL to avoid undesired duplicates do it instead of using an index. Don't create this index if the sole purpose is data integrity/consistency. Indexes get huge so they better be useful for your queries.
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.