FreeLists / oracle-l / RE: Oracle iFS

["Weiss, Ben " <bweiss@xxxxxxxx>]

Hi Tanel,

I sent much of the below to you in response to your offlist email. As I
mentioned, we are also considering scaling up our implementation to handle
terabytes of data, although fortunately not quite as many concurrent users!
I welcome any discussion from the larger list regarding one or more of the
following:
1. Using BLOBs as opposed to BFILE. (Although I'm not sure whether BFILE
would work with the API I mention below)
2. Tuning RETENTION, CACHE, CHUNK SIZE for a particular system's needs.
3. Coming up with test scenarios for stress testing LOB behaviour.
4. Anticipating the migration/maintenance concerns that occur with a
Terabyte sized database. A large percent of the data will be within a single
LOB segment.
5. Strategies for archiving old documents.

Regarding your specific questions below:
1. About 400 database connections. These connections are managed by a
Websphere application server via pooling. I'm not sure of the total number
of end users logged into the application server at any one time, but I can
find out.
2. CACHE: NOCACHE
3. Redo: About 10 MB every 2 minutes.

Also
Oracle version: 9.2.0.4
Current OS & Hardware:
OS: Solaris 2.6
RAM: 7 GB
CPU: 6 cpu @ 400 mhz
Model: E4500

Ben
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Tanel Põder
Sent: Thursday, April 01, 2004 10:34 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Oracle iFS 


Hi Ben!

Thans for posting this information, it seems very interesting. I'm gonna
contact redhat for more information about the API, but I thought to ask you
about Oracle's LOB performance in your environment.

How many concurrent users do you have using this system?
Are your BLOBs CACHE, NOCACHE or CACHE READS mode?
If this is stand-alone database for the doc-management system and the lobs
are LOGGING, then how much redo does the system create?

I'm putting together an architecture for a huge database over 20TB in size,
with about with about 100000 concurrent users. There are quite many
challenges with LOBs, caching and logging - if you want to do write caching,
you get huge logging, if you want nologging, then you can't do write caching
etc..

Tanel.

----- Original Message ----- 
From: Weiss, Ben 
To: 'oracle-l@xxxxxxxxxxxxx' 
Sent: Thursday, April 01, 2004 6:15 PM
Subject: RE: Oracle iFS 


We are using a document management API from Redhat. Cost: $0.00. It's open
source.

You can deploy Oracle Text with it to get full text searching, although we
have not done this. Versioning is supported, as is a drilldown structure.

The application is java, J2EE compliant. We run it via WebSphere. Files are
stored as BLOB within Oracle. We are at 380 GB worth of BLOBs at present.
Meta data, TEMP and UNDO drive total database size up to 440 GB. In our
deployment, the developers tell me we use the API to handle the the
versioning, checkin/checkout and other behind the scenes stuff. The GUI in
our deployment is all built by our developers.

Tricky part is where this API fits into Redhat's marketing approach. They
publicize on their website something called Content Management server, which
is a bit different.

To find out more about the API, you will want to contact Redhat directly,
because it seems hidden from view on the website. This API came from
ArsDigita, a company that RedHat bought. The one place you can read a little
about the API framework is http://ccm.redhat.com. But it makes no specific
mention of document management.

You can contact me directly if I can be of help.

Ben
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Tanel Põder
Sent: Thursday, April 01, 2004 4:39 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Oracle iFS 


My IFS experience is also from 3 years ago, on one of the first public IFS
versions.

We could handle the weekly restarts because of some memory leaks, but when a
virus hit our internal network, it started crawling and modifying all the
files it saw in any mapped drives of workstations, overloading IFS. 
IFS couldn't handle it anymore, eventually we couldn't start up the SMB
cartridge anymore, we hacked our files out using ftp cartridge, copied them
on a regular file server and haven't touched IFS ever since.

It might be a decent product now, thouch (is it still written in Java?)

Tanel.

----- Original Message ----- 
From: Jared.Still@xxxxxxxxxxx 
To: oracle-l@xxxxxxxxxxxxx 
Sent: Wednesday, March 31, 2004 10:12 PM
Subject: Oracle iFS 



Dear list, 

Just asking for experiences using iFS, now called "Oracle Content Management
SDK". 

I'm casting about for ideas to manage IT documents.  The three things that I
see as 
being necessary are these: 

1.  Ability to easily organize a structure that can be easily drilled down
into. 
ie. much like a directory structure 

2. Full text indexing 

3. Versioning - date and time of last edit, who edited the doc, and what
changed. 

Microsoft Indexing service is a no-brainer for 1 and 2, but I don't believe
it does #3. 

iFS seems a likely candidate, though I'm not sure how well it does #3. 

Then there are commercial document management systems.  Way too expensive and 
complex. 

There are alternatives such as KnowledgeTree (open source) but probably just

as much work to setup as Oracle iFS. 

Any good experiences out there with iFS for this type of usage? 

TIA 

Jared 



****************************************************************************
*
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter. 
****************************************************************************
*


*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------