Thanks. I thought it might but was going to check. Now I don't have to. :)
On Thu, Jun 8, 2017 at 11:54 AM, Stefan Knecht <knecht.stefan@xxxxxxxxx>
wrote:
Do note that compressing securefiles requires the advanced compression
option license. It's not "free" with EE.
http://www.oracle.com/technetwork/database/options/compression/advanced-
compression-wp-12c-1896128.pdf
On Thu, Jun 8, 2017 at 3:48 AM, Jeff Chirco <backseatdba@xxxxxxxxx> wrote:
Thanks for your input. Correct in that we have additional information
stored with the LOB that helps for the applications. When we first started
with this project one of the applications ran from Citrix and didn't have
access to a shared folder to store the images so putting it in the database
was easier. But yeah having to manage the backups for this is annoying. I
am going to attempt to partition the table more so I can evntually mark
certain tablespaces as read only so they don't have to get backed up with
regular fulls. I also will look into compressing with securefiles. Thanks!
On Wed, Jun 7, 2017 at 1:27 AM, Gerald Venzl <gerald.venzl@xxxxxxxxxx>
wrote:
The design seems solid. In this scenario databases are often used to
make the documents searchable via the metadata that is stored in the table
next to the LOB, e.g customer, creation date, doc type, etc.
Securefiles allow you to compress the LOB to save more disk space.
You may want to partition on the creation date or something similar,
assuming that those files are queried less when they get older. Then you
can put an ILM strategy in place if you ever have to (compress older files
with a higher compression ratio, etc). The creation date can be even
defaulted to SYSDATE so that you don't have to worry about changing the
INSERT statements.
And, you may want to move to bigfile tablespaces. Nothing wrong with
smallfile tablespaces, bigfile tablespaces just make the datafile
management a bit easier.
Thx,
Gerald
On Jun 7, 2017, at 01:02, Jeff Chirco <backseatdba@xxxxxxxxx> wrote:
Yes they are securelob file
On Tue, Jun 6, 2017 at 12:05 PM, Michael McMullen <ganstadba@xxxxxxxxxxx
wrote:
Are you blobs stored as securefile lobs?
------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx>
on behalf of Jeff Chirco <backseatdba@xxxxxxxxx>
*Sent:* June 5, 2017 7:22 PM
*To:* oracle-l@xxxxxxxxxxxxx
*Subject:* database of blobs
Sort of a design question here. I have a database that is only used to
store documents or images in a blob field. This is mostly scanned copies of
invoices or employee records as pdf's or jpeg images of pictures from some
of our custom applications. Again all of these are stored in the same table
as a blob field. These blob's are currently 840gb in size in a small file
tablespace that currently has 27 datafiles that are 32gb. I potentially
have the opportunity to reorganize this database and or table during an
upcoming migration from 11.2.0.4 -> 12.1.0.2 and also moving Windows ->
Linux.
So I don't really have a direct question here but just wondering what
anybody things about this, or is there something I might want to think
about as this table grows, or maybe a better way to organize it. I thought
about maybe partitioning it somehow but it doesn't seem like there is a
logical way to partition it. Also there are no performance issues as all
this database does is save and retrieve images.
Thanks,
Jeff
