Repository size is increasing !!!!!!!!!

Hello,

Our configuration is BO 4.1 on Windows NT4.0 and Oracle 7.3 on Unix.

We are facing a big problem in the Document domain of the BO repository. The size of the table OBJ_X_DOCUMENTS is increasing continuously. According to the explanation given in the HTML sheet provided with the product CD-ROM, this table is supposed to contain the details of the documents submitted to DAS for refreshing. Hence I thought “Purge the Queue…” option in the DAS might help me in reducing the size and I enabled the same. Even then the size of the table is increasing and I don’t have a clue as to why this is happening.

Has anybody else faced the same problem earlier ? Has this problem been reported by any of you to BO ? Is this a known bug ?

Thanks in advance for any help.

Chandrashekar.S


Listserv Archives (BOB member since 2002-06-25)

=_NextPart_001_01BD92ED.CECA8800"

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.


Listserv Archives (BOB member since 2002-06-25)

Try logging on to supervisor as someone with General Supervisor capability. Use Tools->Repository form the menus. Select the document domain in question. Run a Scan then Repair then Compact. If you just want to shrink it, just use the compact. However, you might as well Scan and Repair it to make sure everything is clean.

Steve Krandel


Listserv Archives (BOB member since 2002-06-25)

I forgot to mention the COMPACT option.

An other reason may be that users are not deleting documents that have been stored in the repository. The way I understand this works is that the queue is managed through the DS_PENDING_JOB table. I think Purge the queue clears this table, but not the documents in OBJ_X_DOCUMENTS.

Yet another reason may be that users store documents in the repository directly. These documents are also stored in OBJ_X_DOCUMENTS.

I don’t think you are facing a bug, rather one needs to understand the inner workings of the different components of the repository. There is quite a good overview of the repository in the FREEWARE directory of the installation CD.

Regards,
Robert Dersigni


Listserv Archives (BOB member since 2002-06-25)

CHANDRASHEKAR schrieb:

Hello,

We are facing a big problem in the Document domain of the BO repository. The size of the table OBJ_X_DOCUMENTS is increasing continuously. According to the explanation given in the HTML sheet provided with the product CD-ROM, this table is supposed to contain the details of the documents submitted to DAS for refreshing.

Not only, it also holds all documents “sent to users”, as well as those “sent to the repository”…

WM

Walter Muellner
Delphi Software GmbH, Vivenotgasse 48, A-1120 Vienna / Austria Tel: +43-1-8151456-12, Fax: +43-1-8151456-21 e-mail: w.muellner@delphi.at, WEB: http://www.delphi.at


Listserv Archives (BOB member since 2002-06-25)

PURGE THE QUEUE deletes only documents from OBJ_X_DOCUMENTS which have been retrieved by the user(s). Upon purging, DS_PENDING_JOB and DS_USER_LIST are also cleaned out.

COMPACT only works on the security domain. Therefore, besides deleting “logically deleted” users, COMPACT will only clean out the OBJ_M_DOCUMENTS table, but will only clean out retrieved documents.

If you need to control the Document Domain, in Supervisor, go to Tools/Delete Document, and delete “Processed documents” to delete documents processed by DocAgent.

Hope this helps,
Luis Gonzalez

From: Dersigni, Robert [SMTP:RDERSIGNI@DOW.COM] Sent: Monday, June 08, 1998 8:20 AM

I forgot to mention the COMPACT option.

An other reason may be that users are not deleting documents that have been stored in the repository. The way I understand this works is that the queue is managed through the DS_PENDING_JOB table. I think Purge the queue clears this table, but not the documents in OBJ_X_DOCUMENTS.

Yet another reason may be that users store documents in the repository directly. These documents are also stored in OBJ_X_DOCUMENTS.


Listserv Archives (BOB member since 2002-06-25)