Re: Snapshot DB's in Exadata?
- From: Aaron Leonard <aachleon@xxxxxxxxx>
- To: Frits Hoogland <frits.hoogland@xxxxxxxxx>
- Date: Fri, 14 Jan 2011 14:14:45 -0600
I wouldn't say it is underperforming because we expect the primary and
snapshot db's to share IO.
Outside of the sharing of IO's in general, the snapshot db's are fast. That
wasn't always the case, of course. We have some tables on SSD, so after the
intial writes against those tables would happen, further reads against those
tables would be against our reserve lun pool (made up of FC disks). Our
reserve lun pool is now made up of SSDs to combat that problem.
On Fri, Jan 14, 2011 at 12:58 PM, Frits Hoogland
<frits.hoogland@xxxxxxxxx>wrote:
> There is a strong case for snapshots. It also moderately easy if you have
> setup the environment to use them (snap, convert the snapped database to
> something which makes it identifyable, startup).
> Have you considered that there is a probability that your system is
> underperforming because of all the snapshots? Not saying it is, just: have
> you checked? (physical io times)
>
> I don't know your exact environment and needs, but also partial/tablespace
> PITR could be an option.
>
>
> Frits Hoogland
>
> http://fritshoogland.wordpress.com
> mailto: frits.hoogland@xxxxxxxxx
> cell: +31-6-53569942
>
>
>
>
> On Jan 14, 2011, at 6:39 PM, Aaron Leonard wrote:
>
> Thanks Frits. I've considered flashback. My concerns with it are
> performance-related. I can't imagine that querying through months of
> flashback logs will satisfy performance needs. Thoughts?
>
> It ~may~ be realistic to convert the few snapshots which live for months
> from snapshots to clones. If I could do that, I'd only need to query
> through a week's worth of flashback logs. The extra space needs could make
> justifying Exadata more difficult. This is the probably my best option at
> the moment though...
>
>
>
> On Fri, Jan 14, 2011 at 4:30 AM, Frits Hoogland
> <frits.hoogland@xxxxxxxxx>wrote:
>
>> as always, it depends on what you exactly need.
>>
>> as has been said, there is no equivalence of storage snapshots. this means
>> you simply can't move the databases over to an exadata and follow the exact
>> same procedure's.
>>
>> however, there is oracle technology which might give the same resolution
>> in a different way. If you want to query the database at different points in
>> time, oracle's flashback technology might be the thing you are looking for.
>>
>> Frits Hoogland
>>
>> http://fritshoogland.wordpress.com
>> mailto: frits.hoogland@xxxxxxxxx
>> cell: +31-6-53569942
>>
>>
>>
>>
>> On Jan 13, 2011, at 9:12 PM, Aaron Leonard wrote:
>>
>> Good afternoon.
>>
>> I'm looking for looking for some advice from those familiar with Exadata.
>> We're currently evaluating a move to Exadata, but our business processes
>> require near-instantaneous snapshot functionality that I don't know if an
>> Exadata system can provide.
>>
>> On various schedules, we take snapshots (EMC storage), mount them r/w to
>> different mountpoints and startup Oracle instances on those. The point is
>> to have fast, point-in-time views of our data, which can be modified and
>> reported on for an extended period of time. At any one time, we have up to
>> 20 different snapshot databases running. Some are retained up to 3 months
>> before we recreated them from a new snapshot.
>>
>> My struggle with giving a thumbs up on Exadata is....how do I make this
>> happen in Exadata? Changing the existing business processes really isn't an
>> option without significant work (possibly years worth) and having to do that
>> really takes away Exadata's appeal. Creating true clones would
>> significantly slow down our overall batch process workflow and negate the
>> justification (which is speeding up that workflow) for moving to Exadata.
>> What are my options, if any? I guess my hope is that Exadata has some
>> undocumented functionality internal to it that does this... Realistically,
>> it probably does not, but since I can't just download one of these and test
>> it out, I have to ask. Any thoughts? Some insight would be greatly
>> appreciated.
>>
>>
>> Thanks,
>> Aaron
>>
>>
>>
>
>
Other related posts:
