Hi,
the issue could still use a better error reporting. Apparently sending concurrent streams to an SO B2D device fails in intricate ways when the data is being ingested, and the resulting errors produce all kinds of other fallout like hanging/freezing sessions. Instead of triggering low level JSONizer data faults, what about preventing concurrent data streams from ever reaching it? Or in case they do anyway, produce a readable message that pinpoints the problem? I had the luck to find an internal memo in the support portal explaining that JSONizer errors may just be caused by inadvertantly concurrent streams, but had I not already developed this suspicion, I'd never found that gem. This is clearly ineffective.
Please also note that there is not always a way to avoid running into this bug as of 9.04. I tried, and I could avoid it for file system objects. But try the following:
- Do a backup of an MSSQL server with concurrency 4 (and enough databases to actually make use of it) to B2D. That means setting Destination Device Load balancing to Min:1 and Max:4, with Application Specific Options/Concurrent Streams:4 (the somewhat recent feature to have other RDBMSs than just Oracle backup in parallel streams). This will send 4 streams to 4 B2D devices instantiated from the destination gateway - works as expected.
- Copy that session to tape, with a destination device Concurrency of at least 4. Will also work well, the four streams are now multiplexed on tape.
- Now copy that tape session to another B2D device. No matter how hard you try to convince DP it will have to write to 4 destination devices and demux the streams to them, it will just instantaneously close all but one of your instantiated target device streams, try to send the multiplexed data to the remaining single device stream, and trigger Mr. JSONizer. That kind of demux works correctly when the session coming from tape is a multiplexed file system (DA) session, and I'm using the exact same Copy Specification that works there, but it fails as described when the session in question is a BAR session (at least for MS SQL, dunno about others - ISTR it didn't happen with IDB sessions though).
So there are cases where the Admin has no control over the multiplexing and will run into the issue even though the configuration is correct. That's clearly a bug, so let's hope it gets fixed one day - but how many more of this kind may lurk somewhere?
HTH,
Andre.
