The secrets of Master Block - Forum - OpenEdge RDBMS - Progress Community

The secrets of Master Block

 Forum

The secrets of Master Block

  • mb_replEnabled can have multiple flags in the field.

    For a replication source database, it will have the SOURCE bit set (bit value of 1); and for the target database, it will have TARGE bit (bit value of 2) set.

    In some rare cases, there could be some other bits set to the field. For example, if a target is in the pre-transition state, it will also have the PRE-TRANSITION bit (bit value of 64) set. So mb_replEnabled of 66 means it's a TARGET database, and it's in PRE-TRANSITION state (66 = 2 + 64).

    If you just need to find out if a database is SOURCE or TARGET, you just need to check if bit (1) or bit (2) is set in the field -- note that we're talking about bitwise operations here.

  • I don't suppose that the _Block VST will ever be of any use in this endeavor?

    --
    Tom Bascom
    tom@wss.com

  • Sending by email.

    Paul Koufalis
    White Star Software

    pk@wss.com
    @oeDBA (https://twitter.com/oeDBA)

    ProTop: The #1 Free OpenEdge DB Monitoring Tool
    http://protop.wss.com
  • > On Apr 19, 2019, at 9:35 AM, ChUIMonster wrote:

    >

    > I don't suppose that the _Block VST will ever be of any use in this endeavor?

    >

    >

    >

    in what endeavor?

    -gus

  • I wrote:

    > mb_repl* fields (except mb_replEnabled) are not zeroes only in source databases.

    Paul's case shows: these fields are identical (non-zeroed) on source and target when a target is in the pre-transition state.

  • The databases are in normal processing, though it is possible that no changes have gone through since the DB was started (this is a test system).

    Paul Koufalis
    White Star Software

    pk@wss.com
    @oeDBA (https://twitter.com/oeDBA)

    ProTop: The #1 Free OpenEdge DB Monitoring Tool
    http://protop.wss.com
  • > mb_replRET            ERROR

    masterblock.sh seems to report the errors occasionally on AIX i.e. if you will re-run the script it may or may not issue the error again for the same database.

      dd if=$2 bs=1 skip=$Offset count=4 2>/dev/null | \
      od -d | \
      awk 'NF<3 {print "ERROR"
    

    Correct behaviour:

    echo 1234 | dd bs=1 skip=0 count=4 2>/dev/null | od
    0000000 031061 032063
    

    IMHO, it's the issue of dd command: its output can sporadically get truncated. I saw the similar issue on Linux but with two dd command in pipe. It was easy to reproduce in test. So it's not a bug of the script. Unforunately I don't know a workaround. Progress is much more reliable than shell scripting. Masterblock.p is more reliable than masterblock.sh. Though the current version of masterblock.sh seems to work reliably on Linux and HP-UX.

  • The errors were definitely intermittent.

    Paul Koufalis
    White Star Software

    pk@wss.com
    @oeDBA (https://twitter.com/oeDBA)

    ProTop: The #1 Free OpenEdge DB Monitoring Tool
    http://protop.wss.com
  • man page for dd on AIX says:

    "The block size values specified with the bs flag must always be a multiple of the physical block size for the media being used"

    but you can use od thusly, without dd:

    od -d -j $Offset -N 4 filename=

  • Thanks, Gus. I'll give it a try.

  • Removing the usage of dd command did fix the issue with masterblock.sh on AIX. Thanks, Gus.

    I uploaded new version of the script in the first post (but the forum engine changed the names of the attached files).

    Additional note:

    proutil -C disablesitereplication does not seem to zero all fields (mb_replai.*, mb_maxArgnclts, mb_lastLogOpSeq) that were set when the replication was enabled. So mb_replEnabled is the only reliable flag to check if the replication is enabled.

  • > I don't suppose that the _Block VST will ever be of any use in this endeavor?

    Would it be useful a 4GL program that can read and parse the database blocks from disk?
    I think it could be used:
    1. as a quick check after the 1124’s: “Wrong dbkey in block”;
    2. to identify the objects that own the blocks reported by after-image scan or by Status: Blocked Clients in promon or by _Connect-Wait* or by Status: Buffer Lock Queue.

    A “plugin” to convert dbkeys in after -image scan into the object’s IDs and/or object’s names can significantly slow down the scan of AI files. Would the new information worth the time lost during the scan?

    It’s not hard to write a program that would parse only the block headers. Though my first attempt was failed due to a Progress bug: sometimes Progress read data from a wrong offset when the offset was larger than 2GB. I hope the bug is fixed now. Also program could optionally parse the context of whole block using the same trick as the viewdbblock script.