BladeLogic database details explained to some (very small) extent

Version 2


    This is in NO WAY anything official and you NEVER should use this information to change any content of the BL-database.


    This is for informational purposes only - technically speaking this is "read-only"-information. And it contains my personal findings about some relationship inside the "bladelogic"'s-(Oracle-)-database-schema.


    I found this details by comparing GUI-data with database table data in a "sandbox"ed TEST-environment!!! If you are like me just interested in some deeper understanding of what's happening "behind the scenes" - you are invited to read on.


    This document is WORK IN PROGRESS. It may CONTAIN ERRORS. Please comment on this to improve it.


    And one last word (because it's so important): DON'T (never ever - you got it?) change anything in any database based on this information. That's solely subject to be guided by the support staff!


    And now - here comes the fun stuff




    The magic ever continuing job.


    The problem:

    Point of origin was a job (NSHScript-job) running against about 1000 targets which - for only ONE target - failed over and over again showing "Already running" in the job log. But there was no task running, there was no process running, furthermore most of the application servers have been restarted in the meantime - including the database server. The job was still marked as "already running"... The magic ever continuing job (so, here is where the title comes from )


    The investigation:

    Some day  - it really was no important server as you could imagine, just a test server in some very unimportant part of the galaxy- we went down the job history (about 35 pages in BL-GUI, the job runs every hour). With "trial & error" we finally got the first job that failed. There were a bunch of other errors in this job run and one I've never seen before: DB_ERROR. Wow. That's some point to really start the practical search.


    First idea was JOB_RUN (I write tablesnames in capital letters like thay are in the Oracle-database - btw. I assume that the MS-SQLServer database is equal in terms of tables, indexes and so on but that's not my area - excuse me, if there's some difference). But JOB_RUN contains only information about a job run (yes, really  ) - but no information about different targets. So we continued our research. JOB_RUN_EVENT is another interesting table. It contains something like SERVER_NAME (I write column-names also in capital letters). Here we have the posibility to make a distinction between successful and failed targets. Also we found a bunch of *_ID-columns but nothing that looked like the information we searched: a status (i.e. already running) and some start-time and end-time for this target.


    Then we tried the "brute force"-method (yes, in a SANDBOXed environment) - selecting all table-data into a text file and analyzing this text-file with my favorite tools: grep and egrep . And suddenly we found the magic column...


    But - was it the right column? Did we detect the "magic ever continuing job"? And - of course - did Peter and Mary Jane ever get married?

    --- to be continued ---



    This is just to get things rolling, and to keep myself close to this topic - I'm now on vacation for ten days and will return to this document in about two weeks - so hold on! Stay tuned!


    And - please comment! Also on spelling errors - I'm no native english-speaker/writer, thankfully I have the www. Should I - in further additions - just pin down the facts (tableX, columny, doThis, dontDoThat) or do you like this "kind of story"-style?