Remove old objects from Livelink?

[DrDDT]

Hi all,

We upgraded a test system to LL9.5SP1, but some of the modules installed were no longer required, or not upgradable.

For these modules, some Livelink objects still exist in the system, like Appearance XML objects en LL Instant messenger presence objects.

These objects are no longer accessable because the modules are no longer present on the system.

What is the easiest way to remove these objects, or more specific, how to remove all objects of a specific type from the system. Can I use a LiveReport for this?

 

[appnair]

usually most times the uninstall program takes care of that.In this case you need to talk to OpenText or whoever provided the module and request a cleanup script.If I wrote code and came up with the orphaned scenario I will probably go thru a recommended practice which is to run a customverification (see verification objects in admin.index).The database verification will probably tell you the orphans and stuff like that.I would process the result set thru a nodedelete call.
One more thing if you can share what kind of hardware memory do you have on the admin server.I recently got a 9.5 sp1 and it is giving me a very slow search/index builup.After 4 days of upgarde I am not even 1 % indexed on a 3 GB ram server

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[DrDDT]

The objects are not showing up on a database verify, but I can easily find out the object subtype numbers. OpenText told me to use a cleanupscript, but I thought some generic 'remove all objects of a certain subtype' thingy should be out there somewhere.

We're running a test system with a Xeon 2.8 en 2GB ram.
The index is very small though, indexing was just as fast as the previous version (9.1sp3).

The coming weeks we're upgrading the acceptance system with ~250.000 documents running on the very same hardware. I can tell you more then.

 

[appnair]

Well if you can try a nodedelete through Oscript that will take care of database referential integrity,clean index etc.As a test write a small lapi/oscript program and hardcode one of the nodes you are trying to delete.If it works then you can probably run the resultset of your filter subtype query and see how it goes.the only reason I say thay you should not use direct sql is because the app may never know what happened.

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[Syntergy]

An easy approach is to delete the object from dtree. If you know the subtype you can execute the following SQL:

delete from dtree where subtype = 1234

The problem with that is if there is related data in other tables. It typically doesn't cause a problem to have data in the related tables if the dtree entry is gone. The common related tables are dversdata for document type objects, daudit (audit trail info) and dtreeacl (permission info).

A less risky approach is to change the parentid of the known objects to some place in Livelink that users do not have access to. You can use the following SQL to update the parentid for an object:

update dtree set parentid = 5678 where dataid = 1234

or if there are a lot of objects to move you could do it by subtype

update dtree set parentid = 5678 where subtype = 1234

(Remember to do a commit after executing the SQL above.)

The problem with that approach is that you can easily get too many objects in one folder making it time consuming to browse that folder if you needed to for some reason.

The safest approach is to install the old modules temporarily, delete the objects, then uninstall the modules again. The object delete will remove the dtree record and any data from secondary tables.

 

[DrDDT]

Well...... running ipool.autocreation and starting the index process hangs the database server (oracle) in 100% cpu usage.

After a full day only 12.000 documents were indexed, and the index doesn't restart after a database restart.

I logged a call with OpenText on this issue.

 

[appnair]

Same here with me fifteen days on a test db around 115000 hits.It sucks.At least on mine there are no errors but is sooooo slooow.It is taking its sweet time about it

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[DrDDT]

Wel, our indexing probs are fixed.

The july patch remove a 'SQL loop' bug, and our database needed some tuning.

After that, indexing was back to the old speed.

 

[appnair]

I jsut installed the July patch.Our indexing was stack crawling to no extent.we still have a lot of memory problems on our servers.

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[davidt50]

what is your stack crawl?