RE: storing blobs in database

From: Jeff Chirco <JChirco_at_innout.com>
Date: Wed, 18 Jan 2012 15:48:25 +0000
Message-ID: <6D9F00643B733E489E419CB485C966271C1384_at_IRVMBX01.innout.corp>



Thanks for the reply.
I don't have any experience with read only tablespace, do they just need to be backed up once?

Also another thing to think about is that our database Sits on a NetApp SAN and we creating clones of our production servers all the time and I don't really want to slow this process down any.

-----Original Message-----
From: Martin Nash [mailto:martin_at_orasavon.com] Sent: Tuesday, January 17, 2012 1:56 PM
To: Jeff Chirco
Subject: Re: storing blobs in database

Hi Jeff,

Based on what you've described I would definitely recommend a single database for the following reasons:

  1. Only one set of instance processes running on your server
  2. You are only managing memory in a single instances
  3. You can be sure that recovery will be consistent between BLOBs and other data
  4. If the PDFs are static then once they are created you could use daily/weekly/months (depending on data volume) partitions with a tablepsace per partition and make the tablespaces read only once they will not be written to anymore. This way you can be comfortable to back them up far less often than the non-readonly tablespaces
  5. Application only has to connect to a single database

With respect to the Data Guard element, if your non-BLOB data is important enough to protect with Data Guard then isn't the BLOB data too?

Martin

On 17 Jan 2012, at 21:19, Jeff Chirco wrote:

> I am going to use SecureFiles, which is still a blob though. I forgot to mention that our main production data is part of a physical data guard environment so I am not sure if that changes anything. Also, we plan on encrypting these blobs, which SecureFiles will come in handy. And I don't need a new EE license since I plan on make the database on the same server as my main production instance.
> Also these pdf's will be static once they are created.
> I will need regular backups of this blob data, we can't afford to
> loose it. And I am not sure yet but it might need to be consistent with the backups on our main production database because there will be a document ID value that will be used in other applications on our main database.
>
> From: andyklock_at_gmail.com [mailto:andyklock_at_gmail.com] On Behalf Of
> Andy Klock
> Sent: Tuesday, January 17, 2012 12:31 PM
> To: Gsais_at_mypalmbeachclerk.com
> Cc: Jeff Chirco; oracle-l_at_freelists.org
> Subject: Re: storing blobs in database
>
> I happen to think databases are a nice place to store documents. With 11.2 I'd definitely recommend using SecureFiles over BLOBS. As for backup times, you'll have to decide the impact or if there are other ways to speed up the rman times. Static pdf files can be placed in a readonly tablespace, add more parallel to your backups, or doing incrementals with block change tracking (to name a few). By adding a new EE database you've added more license fees.
>
> But definitely look into securefiles.
>
> Andy
>
> We are working on an application that will store images, well actualy pdf's in our database. We are debating on storing the blobs in our main production database or creating a separate database just for these images. We have applications running on our main production database that will need to pull these across to display. I am thinking a second database is the best idea since this database will get rather large very quickly and I don't want to slow down the backup of my main production database. Does anybody else do something similar to this and can provide your experiences. We are running 11.2.0.2 Enterprise Edition on Windows Server 20003 R2, soon to be 2008.
> Thanks.
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 18 2012 - 09:48:25 CST

Original text of this message