Kategorie: Technik

Monitoring von Documentum DCM 6.5

Eines vorweg: „Monitoring“ ist ein wenig übertrieben… Jedoch habe ich mit der Zeit gelernt, dass es von Nutzen sein kann, ein paar Werte immer im Blick zu haben. Im folgenden möchte ich kurz beschreiben, wie ich dabei vorgegangen bin.

Auf einem der Content Server läuft alle 15 Minuten ein Job, welcher ein Skript anstösst, dieses sieht vereinfacht wie folgt aus:

Pfad zu idql.exe docbase -UAdminBenutzer -P -n pfad_zum_dql_skript.dql > logfile.log

IDQL ist auf dem Content Server vorhanden und dadurch dass es auch auf diesem ausgeführt wird, ist kein Passwort erforderlich. Das so erstellt Logfile werte ich mit einem kleinen VB-Skript aus und versende gegebenfalls eine SMS / Mail.

Folgende DQL Skripts lasse ich dabei jeweils laufen:

„Schlafende“ Workflows: Wenn viele Workflows zum verarbeiten anstehen, ist das noch nichts tragisches, kann aber manchmal der Vorbote für gröbere Probleme sein.

SELECT   count(*) FROM  dmi_workitem WHERE  r_runtime_state < 2 and  r_auto_method_id <> ‚0000000000000000‘;go

Paused Workflows: ALARM! Der Java Method Server hat ein Problem und muss neu gestartet werden.

select count(distinct f.r_object_id)from dm_workflow f, dmi_workitem i, dm_activity a, dmi_package p, dm_sysobject(all) s where f.r_object_id = i.r_workflow_id and f.r_object_id = p.r_workflow_id and p.r_component_id = s.r_object_id and i.r_act_def_id = a.r_object_id and i.r_runtime_state > 3 and f.r_runtime_state < 4 and s.object_name like ‚%‘ and f.object_name like ‚%’order by i.r_creation_date desc , i.r_act_seqnoenable(ROW_BASED); go

FAST Queue: FAST ist die Fulltext Engine vom DCM 6.5 SP1. Wenn diese den Content nicht mehr indexiert, sammeln sich die Objekte in dieser Queue an.

SELECT   count(*) FROM  dmi_queue_item WHERE  name=’dm_fulltext_index_user‘ and  task_state is nullstring; go

Rendition Queue: Wenn dort Objekte länger als 15min drin sind, stimmt da sicher was nicht….

SELECT  count(*) FROM  dm_queue WHERE  name in (‚dm_mediaserver‘, ‚dm_autorender_win31‘, ‚dcm_custom_job‘) and  date_sent > (DATE(NOW)-(60*0.000694)) and  date_sent < (DATE(NOW)-(1*0.000694))ORDER BY  sign_off_user desc, priority DESC, date_sent ASC; go

Das ganze lässt sich beliebig ausbauen und auf die persönlichen Bedürfnisse anpassen. Neben einer professionellen Lösung mag dies lächerlich aussehen, aber die oben beschriebenen Skripts sind schnell implementiert, funktionieren und ermöglichen es mir, rechtzeitig zu reagieren.

Das erste Notebook

Seit etwas mehr als einer Woche habe ich nun mein Macbook Air 11″, und ich bin immer noch voll begeistert. Eigentlich habe ich es als Ersatz für mein Netbook gekauft, aber es ist eigentlich ein vollständiger Computer. Bis jetzt habe ich nichts gefunden, was mich stören würde, im Gegenteil:

Das Display hat ne super Auflösung (1366×768) und ein super Kontrast, das Notebook (oder Netbook) macht nie ein Geräusch, sprich es läuft nie ein Lüfter, bootet in… wenige Sekunden, Anwendungen starten schnell und und und… zwei Punkte gefallen mir besonders gut:

  • Das Trackpad ist genial: Es löscht mir nicht den ganzen Text weg, wenn ich einmal mit den Handballen drauf komme und die Gestenunterstützung macht die Bedienung super komfortabel.
  • Deckel zu: Standby, Deckel auf: Ohne Verzögerung wieder da und einsatzbereit.

Dadurch ist es für mich ein echtes Notebook (Notizblock), ich habe es bis jetzt immer dabei gehabt und nutzte es unterwegs um Aufgaben und Notizen zu verwalten und Zuhause für alles andere. Ich habe mein Netbook verkauft und (unbewusst) einen vollständigen Computer gekauft, der Mehrpreis von rund Fr. 700.– gegenüber einem Netbook ist voll gerechtfertigt, da es eben doch ein Notebook ist 🙂

 

Wiederherstellen von gelöschtem Content in Documentum DCM

Der folgende Beitrag beschreibt das Wiederherstellen von gelöschtem Content in Documentum DCM 6.5, nachdem die Jobs dm_dmclean und dm_dmfilescan bereits gelaufen sind. Der Content sowie die Datenbank muss in Form eines Backups von vor dem Löschen vorhanden sein. Das Vorgehen eignet sich eher für eine grosse Anzahl Objekte, da sonst der Aufwand wohl zu gross ist.

Wenn nicht bekannt ist, wann die Dokumente gelöscht wurden, muss dies zuerst ermittelt werden. Am einfachsten geht das mit folgendem DQL Query:

<span style="color: #3366ff;">SELECT * FROM dm_audittrail WHERE event_name = 'dm_destroy' and user_name = 'username' and time_stamp &gt; Date('20.08.2010') and time_stamp &lt;= Date('10.09.2010')</span>

Achtung: Das Query könnte eine hohe Last auf dem System verursachen….

 

Anschliessend muss die Datenbank sowie der Content von vor dem Löschen wiederhergestellt werden. (z.B DB Server als virtueller Clone des ursprünglichen DB-Servers). Anschliessend benutzt man die audited_obj_id vom Resultat von oben, um ein SQL Script auf der zurückgesicherten Datenbank laufen zu lassen:

 

<span style="color: #3366ff;">connect username/password@database; set heading off SELECT ALL data_ticket FROM dmr_content_s WHERE full_format LIKE '%8%'  </span><span style="color: #3366ff;">and (r_object_id in (select r_object_id from dmr_content_r where parent_id = 'audited_obj_id'));</span>

<span style="color: #3366ff;">... set heading on exit;</span>

Interessant ist hier das Attribut data_ticket, dieses in HEX umgerechet entspricht dem Pfad im Filesystem.

 

Am einfachsten wird es sein, die Ausgabe vom ersten DQL Query als Excel-Datei zu exportieren. So können anschliessend die data_tickets hineinkopiert und via DEC2HEX Funktion umgerechnet werden.