For how many years have you been working
with physical servers that are starving your database of the memory
necessary to deploy important new performance features such as the Result
Cache, Memoptimize Pool, In-Memory Aggregation, In-Memory Column Store, and
Full Database Caching? Too long? Contact me to learn how to improve all
queries ... not just some queries.
You can use the transportable tablespaces feature to move a subset of an Oracle database and "plug" it in to another Oracle database, essentially moving tablespaces between the databases.
The tablespaces being transported can be either dictionary managed or locally managed. Starting with Oracle9i, the transported tablespaces were not required to be of the same block size as the target database's standard block size.
Transporting tablespaces is particularly useful for:
Moving data from OLTP systems to data warehouse staging systems Updating data warehouses and data marts from staging systems Loading data marts from central data
warehouses Archiving OLTP and data warehouse systems efficiently Data publishing to internal and external customers Performing Tablespace Point-in-Time Recovery (TSPITR)
Moving data using transportable tablespaces can be much faster than performing either an export/import or unload/load of the same data, because transporting a tablespace only requires the copying of datafiles and integrating the
tablespace structural information. You can also use transportable tablespaces to move index data, thereby avoiding the index rebuilds you would have to perform when importing or loading table data.
Be aware of the following limitations as you plan for transportable tablespace use:
The source and target database must be on the same hardware platform. For example, you can transport tablespaces between Sun Solaris Oracle databases, or you can transport tablespaces between Windows NT Oracle databases.
However, you cannot transport a tablespace from a Sun Solaris Oracle database to a Windows database. The source and target database must use the same character set and national character set.
You cannot transport a tablespace to a target database in which a tablespace with the same name already exists. Transportable tablespaces do not support: Materialized views/replication Function-based indexes.
New in 12.2
TDE, in 12.2 supports ARIA, GOST, and SEED encryption algorithms.
ARIA (Academia, Research Institute, and Agency) for South Korea
GOST (GOsudarstvennyy STandart) for Russia
SEED (Korea Information Security Agency (KISA) for South Korea
This feature includes support for both encryption and hashing algorithms and is available for use with data-at-rest encryption. Certain countries require the use of their specific national and government standards for encryption.
Deployment of TDE database encryption in these countries can proceed now that these national and government algorithms are supported.
conn sys@pdbdev as sysdba
set pagesize 35
col platform_name format a35
ORDER BY 1;
CREATE TABLESPACE tts
DATAFILE 'c:\temp\tts.dbf' size 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
SEGMENT SPACE MANAGEMENT AUTO
SELECT tablespace_name, contents, status
CREATE OR REPLACE DIRECTORY trans_dir AS 'c:\tts';
GRANT READ, WRITE ON DIRECTORY trans_dir TO public;