To answer your second question first: yes you should partition. Oracle's query optimizer has a feature called partition elimination, which will check the predicate for the partition and only execute the SQL on the appropriate partitions.
Partitioning also leaves all the data in one space. Conceptually, think of it as many tables of identical structure, with an implicit UNION ALL
between them if you were to do a SELECT
from the entire table. Except "under the hood" Oracle sorts the actual rows into the right "table" based on the criteria you specify. Any rows that come in that don't match any of the criteria, go into what's known as the "default" partition.
For what you want to do, a "range partition" might be a good approach (so you can add more tenants later), e.g.:
create table transaction (id, tenant_id, a, b, c, d)
partition by range(tenant_id)
partition p_tenant1 values less than (2) tablespace ts_tenant1
partition p_tenant2 values less than (3) tablespace ts_tenant2
partition p_tenant3 values less than (4) tablespace ts_tenant3
partition p_tenantd values less than (MAXVALUE) tablespace ts_default;
Then later
alter table transaction
add partition p_tenant4 values less than (5) tablespace ts_tenant4;
This will create something that looks and behaves just like a normal table, but actually rows where tenant_id=1 will be in a partition in tablespace ts_tenant1, and queries will ignore all other partitions. Queries across the entire table can run in parallel on each partition. If tenant_id=4 in this scenario, the row will live in ts_default unless you add the new partition as shown, but the INSERT
won't be rejected because there's no partition for it!
FWIW At my site we use partitioned tables in our 40Tb DW, you don't need to worry about this approach scaling or performing, if you choose your partitioning strategy well (e.g. you could partition on tenant_id then subpartition on month perhaps), create the right indexes, and so on.
Tablespace size is not changed by creating, dropping or importing tables (if we forget autoextend option). If your tablespace has no data after droping tables, it is easy to resize datafiles or recreate tablespace. If not empty tablespace, after tables drop, you can try to resize datafiles ALTER DATABASE DATAFILE 'file1' RESIZE 20000m.
Note that resizing may not always be done if your tablespace still contain some tables/indexes. In this case you will need to do some other actions before resizing... (alter table move or drop+import or...)
Best Answer
10 GB as 10240
MiB
?10 GB as 10000
MB
?Is it 10 GB because of the rounding, but the actual size is 10227
MiB
? Or 10213MiB
?Setting
db_recovery_file_dest_size
to 10G means the size of FRA will be 10*1024*1024*1024 = 10737418240 bytes. As long as that is less than or equal to the available space in the filesystem (not partition!), it should be fine.I usually set
db_recovery_file_dest_size
a bit smaller than the amount of free space in the filesystem or ASM diskgroup if I get a dedicated filesystem or diskgroup for it.