dmi_queue_item

Hello,

we have a client that uses Documentum and recently complained that the database is too big (1 terabyte).

We have already set a job to clean the dm_audittrail table.

I analyzed the tables in the database and I realized that the main responsibility for the database size is the dmi_queue_item (about 49.5% from the whole database).

I extracted some data related to this table, it follows below:

1. number of records: 265 402 394

2. those with delete_flag = true: 84 969 - I know how to clean them

3. those with delete_flag = false, grouped by event

- dm_checkin: 20 271

- dm_destroy: 19 927

- dm_move_content: 143 215 038

- dm_readonlysave: 20534

- dm_save: 122 033 913

- DM_SYSADMIN: 66

- dm_unlock: 1

- Job_Failure: 8091

- wcmerror_procedure_error

I know that I can delete the ones that are just notifications - DM_SYSADMIN and Job_Failure.

The problem is that their count is too small in comparison with the other ones.

My question is IS IT SAFE to delete also dm_checkin, dm_destroy, dm_move_content, dm_readonlysave, dm_save?

Thanks

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

DCTM_Guru

1) dmi_queue_items are used by workflow engine as well as other Documentum products that want to use queue. For example, Content Transformation Services also uses queues to "submit" documents to be transformed. You statement is true if you explicitly say that dmi_queue_items whose name='dm_fulltext_index_user' is used exclusively by xPlore.

2) It could be that your xPlore agent has not been running and therefore, none of your content has been indexed by xPlore search engine. If this is the case, then you shouldnt just delete any old queue items.

All comments

Andrea Paci

Hi,

By the looks of it, I am under the impression that those dmi_queue_item objects are the result of the events registered for fullext indexing; you can confirm this by looking at the name they have been queued for (it should show dm_fulltext_index_user).

If you are not using xPlore, you can delete the dmi_queue_item objects under the name of the dm_fulltext_index_user and unregister the events that triggered them.

Check the Documentum xPlore 1.5 Administration and Development Guide for details.

Good luck!

martin.dimitrov

Hello,

thank you for the quick answer.

I have two questions:

1) Is it true that ONLY if using xPlore these events are generated, e.g. some data is written in dmi_queue_item where the event is dm_save (for example)?

2) I will check if this is the case (using xPlore) but even so can I safely delete the old ones?

thanks,

Martin

Haroon_A



If you are not using xPlore, you can delete the dmi_queue_item objects under the name of the dm_fulltext_index_user and unregister the events that triggered them.

But if we use xPore, aren't these queue items supposed to be removed, once the request is processed by xPlore?

martin.dimitrov

Ahmad Sakhi: It seems that they are not being deleted.

Since it's a big enterprise I really need to know the answers of my questions:

1) Is it true that ONLY if using xPlore these events are generated, e.g. some data is written in dmi_queue_item where the event is dm_save (for example)?

2) I will check if this is the case (using xPlore) but even so can I safely delete the old ones?

thanks a lot

P.S. You understand, I don't want to delete something that will crash the production, it's a big bank in my country.

DCTM_Guru

Haroon_A

Johnny - So, it means that once the dmi_queue_item for xPlore (name=dm_full_text_user) is processed, then that dmi_queu_item should be removed, correct?

jdesouza@furnas.com.br

Well .. I have a opinion that if most of events are to XPLORE user, you can delete them if the table size is problem for you (1TB). You can narrow another index Agent after to this docbase in Migration Mode and you will recover all these events (it would be better because most these events probably will fail with duplicate error). While one indexAgent searchs, the other one will migrate from the first to the last R_object_id.

About Workflow Events, the scenario is diferent.. I shouldn't delete them..

Filter you query not by the events but by the user_event and decide what delete !!!

Enviado do meu iPhone

Em 20 de out de 2016, às 19:26, Haroon_A <emc-community-network@emc.com> escreveu:
DECN
dmi_queue_item
resposta de Ahmad Sakhi em Documentum - Visualize a discussão completa
Johnny - So, it means that once the dmi_queue_item for xPlore (name=dm_full_text_user) is processed, then that dmi_queu_item should be removed, correct?
Responda a esta mensagem respondendo a este e-mail ou vá para a mensagem em DECN
Inicie uma nova discussão em Documentum por e-mail ou em DECN
Seguindo Documentum nestes fluxos: Caixa de Entrada

AVISO

Esta mensagem e destinada exclusivamente a(s) pessoa(s) indicada(s) como destinatario(s), podendo conter informacoes confidenciais, protegidas por lei. A transmissao incorreta da mensagem nao acarreta a perda de sua confidencialidade. Caso esta mensagem tenha sido recebida por engano, solicitamos que seja devolvida ao remetente e apagada imediatamente de seu sistema. E vedado a qualquer pessoa que nao seja destinatario usar, revelar, distribuir ou copiar, ainda que parcialmente, esta mensagem.

DCTM_Guru

"it means that once the dmi_queue_item for xPlore (name=dm_full_text_user) is processed, then that dmi_queu_item should be removed, correct?"

- It should be. I vaguely remember that one of the queue item attributes also contains the status of the indexing for that particular document. If its been "processed", then it can be removed.

Haroon_A

Try running this query, and analyze the "message" field. This contains the warning/error message for the items
that xPlore most probably failed to index.


SELECT 
     r_object_id, 
     name, 
     event, 
     item_name, 
     item_type, 
     message, 
     task_state, 
     read_flag, 
     delete_flag, 
     dequeued_by, 
     i_event_flags 
FROM 
     dmi_queue_item 
WHERE  
     delete_flag = false AND 
     name='dm_fulltext_index_user'

DCTM_Guru

I believe a blank value in message attribute means its waiting to be indexed, but I dont remember if that field is updated when indexed has completed successfully (or whether the actual dm_queue_item is actually deleted).

martin.dimitrov

Hello,

today I was at the client.

I confirmed that most (98%) of the records result from name='dm_fulltext_index_user'.

I ran the following query

select count(*) from dmi_queue_item_s where name='dm_fulltext_index_user'

Our client is NOT using xPlore and fulltext indexing (or even if installed they don't need it)

Am I correct to assume that I can delete all of these records (which will free 30% of the database)?

Please, advise me before doing something that can damage the production.

thanks,

Martin

Andrea Paci

Hi ,

Yes, in your case it should be safe to delete the queue items in the name of the dm_fulltext_index_user since xPlore is not used. Deleting such a large number of queue items via DQL can take a long time and even take the repository down. You should use this other aproach:

1. Shut down Docbase and take database backup. You must stop the repository or users accessing workflow/queue items may cause unexpected behavior.

2. Create a temp table and store all dmi_queue_item objects that are not in the name of the dm_fulltext_index_user.

3. Truncate the dmi_queue_item_s table. This does not create a transaction log, and it should delete everything in dmi_queue_item_s table immediately.

4. Insert everything you copied in step 2 from the temp table back into the dmi_queue_item_s (without entries for dm_fulltext_index_user).

5. Restart the Docbase.

This has been documented in KB 307032 - How to delete large numbers of dmi_queue_item objects - https://support.emc.com/kb/307032

Remember that you should unregister the fulltext related events! Check the Documentum xPlore 1.5 Administration and Development Guide for details.

Regards,

Andrea Paci

martin.dimitrov

Hello Andrea,

thank you very much for the confirmation and the instructions how to proceed.

Best regards,

Martin

ravivo2001

Dear Andrea,

Since OT took over, I believe that the correct link for the KB is this one:

knowledge.opentext.com/knowledge/llisapi.dll/kcs/kbarticle/view/KB8586580

Thanks