A good use case re worrying about stream order is when scripters try to use 'bpstart_notify' to take down a database for... what they see... as a specific stream number. But because the 'stream_number' is never guaranteed, then how does one ensure that a database is down before a multi-streamed backup occurs for a specific drive?
The feature of 'stream_count' and 'stream_number' beaing available in bpstart_nootify and bpend_notify scripts would "seem" to be useful feature - but really it is a red herring and is nearly useless because stream order cannot be guaranteed.
.
There are, as I see it, only a few options:
1) Don't use multi-streaming - and so no need to try to base database down or database up actions within bpstart_notify and bpend_notify based on stream_number. But this can be impractical for some servers where we need to take down a database for the shortest possible time.
2) Break the policy in to two (or more policies) - and use policy 1 to backup all drives not containing a database, and use policy 2 to backup just the drive containing the database - and thus a bpstart_notify.POLICYNAME and bpend_notify.POLICYNAME which is specific to that one policy for that one drive/path containing the database which needs to be shutdown before a backup occurs and restarted when the backup ends.
3) Above I said that the 'stream_number' is nearly useless - and I say nearly... because it still has one use... in that a customer/user can still use multi-streaming and still use bpstart_notify to take an 'offline database' backup - but only if max_jobs is also set to 1... i.e. bpstart_notify can be scripted to take an offline database backup IF it is running as stream 1 - i.e. there is always a stream 1, and if max_jobs for the client or policy is 1 - then there can only be 1 stream running - and so during stream 1 it is a good place/time to take an off-line database backup - so that later subsequent streams pass over and take a copy of the dumped/exported/copied database files.
.
So, because stream order cannot be guranteed, what would be more useful is if the 'path/paths' for a stream could be made accessible to bpstart_notify - i.e. if there was another system variable, e.g. "STREAM_PATHS" would could contain a list of the paths for that stream - then we could genuinely have stream specific actions coded in our bpstart_notify and bpend_notify scripts.
