Re: Intelligent Data Placement - IDP question regarding using this for different physical devices

From: Kevin Jernigan <kevin.jernigan_at_oracle.com>
Date: Thu, 15 Aug 2013 01:13:13 -0400
Message-ID: <520C6369.5010803_at_oracle.com>



Heat Map and ADO do not work with Multitenant databases in 12.1.0.1. They will be supported in a future release, not sure yet if it will be the first patch set on 12c (12.1.0.2), or if it will be in 12.2. -KJ
-- 
Kevin Jernigan
Senior Director Product Management
Advanced Compression, Hybrid Columnar
Compression (HCC), Database File System
(DBFS), SecureFiles, Database Smart Flash
Cache, Total Recall, Database Resource
Manager (DBRM), Direct NFS Client (dNFS),
Continuous Query Notification (CQN),
Index Organized Tables (IOT), Information
Lifecycle Management (ILM)
(650) 607-0392 (o)
(415) 710-8828 (m)

On 8/15/13 12:43 AM, joshuasingham wrote:

>
> Hi Kevin,
>
> Just wanted to check with you if ADO is supported in the pluggable
> database from what I have read I believe it is not , do you know when
> will it be supported for pdb
>
> Regards
>
> Joshua
>
> On 15 Aug 2013 12:23, "Kevin Jernigan" <kevin.jernigan_at_oracle.com
> <mailto:kevin.jernigan_at_oracle.com>> wrote:
>
> Rumpi,
> I assume you're referring to the IDP feature of ASM. I checked
> with ASM
> product management, and they responded:
>
> Unfortunately, IDP does not work the way the OP envisioned. IDP
> allocates within a single device using low-ordered LBA ranges as
> higher
> performance. It is typical that for standard rotating disks, low
> ordered
> LBA accesses offer better performance than higher-ordered LBA ranges.
> Furthermore, this is not even true for SSD-based devices. I
> invented the
> concept of IDP before SSD devices were common place. IDP does not
> cause
> preferential allocation across different device classes.
> Consequential,
> this scheme will not work...
>
> However, in Oracle Database 12c, the Heat Map and Automatic Data
> Optimization (ADO) features are designed to do exactly as you
> describe.
> You can set up ADO policies on a tablespace to cause the coldest
> partitions in that tablespace to be moved to a different tablespace,
> presumably on more cost-effective storage, when the original
> tablespace
> becomes too full based on a threshold you can set. You can also create
> ADO policies that compress data based on Heat Map-collected data, and
> you can even create custom conditions for your ADO policies, to
> trigger
> movement or compression of data based on any conditions that you can
> code in a PL/SQL function.
>
> Are there specifics to your scenario where this approach doesn't help
> (other than the likelihood that you haven't upgraded to 12c yet)?
>
> -KJ
>
> --
> Kevin Jernigan
> Senior Director Product Management
> Advanced Compression, Hybrid Columnar
> Compression (HCC), Database File System
> (DBFS), SecureFiles, Database Smart Flash
> Cache, Total Recall, Database Resource
> Manager (DBRM), Direct NFS Client (dNFS),
> Continuous Query Notification (CQN),
> Index Organized Tables (IOT), Information
> Lifecycle Management (ILM)
> (650) 607-0392 <tel:%28650%29%20607-0392> (o)
> (415) 710-8828 <tel:%28415%29%20710-8828> (m)
>
> On 8/14/13 3:00 PM, Rumpi Gravenstein wrote:
> > We have purchased SSD storage for our servers . This storage is
> assigned to
> > UNDO, Flashback Archive and TEMP. Unfortunately we now need
> more space and
> > have max'd out our ability to add SSD storage to the server.
> > An approach we are considering is to use IDP to effectively
> "extend" our
> > SSD devices assigning our existing SSD storage to HOT and adding
> additional
> > SAN storage as COLD.
> >
> > So here's the question -- has anyone looked at IDP and how well
> it manages
> > the HOT/COLD assignments. Ideally we would want HOT areas to
> completely
> > fill before we spill over to cold. I'm also interested in
> general thoughts
> > on using IDP in this way.
> >
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-l
Received on Thu Aug 15 2013 - 07:13:13 CEST

Original text of this message