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.
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.
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.
I have a production table. The table is updating and deleting rows daily. So want to know about how many space allowed per table in oracle 10g and 11g? If exceed the limit how we fix the problem?
Practically, there is no limit. At least not one that any human is likely to hit.
If you want to be pedantic, a bigfile tablespace can be up to 32 TB in size if the database is using 8k blocks or 128 TB if the database is using 32k blocks. A table can have up to 1024k partitions. Each partition could be in a different tablespace but you can only have 64k tablespaces. So if you have 64k partitions and each partition in a separate bigfile tablespace with nothing else in the tablespace, you could have up to 128 TB * 64k = 8192 PB = 8 EB (exabytes). That's roughly 1,000 times all the data stored in the Library of Congress. If your table is that large, you've done something extraordinarily wrong.
Each version of the database has a couple of sections in the Oracle Reference on the physical limits and on the logical limits of the database that you can use to answer these sorts of questions.
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.