Backups are often the last thing some people think of and usually the first they look for when things go wrong...
Most applications out 'there' use a single database as a source and backing up the data is a simple matter of backing up that specific database. When you deal with an OLTP system then things get a bit harder as your backups can influence the running system (lock tables etc.). Even that is fairly easy to solve these days with transaction log backups or log shipping.
When you get to a system like BizTalk there is an even bigger problem. BizTalk uses multiple databases to store all weird and wonderful things that must transactionally match up. In other words, transactions and their state span across databases! Backing up just one database alone or all in serial is not going to cut it when you have to restore it to a transactional 'sound' state. For that reason the designers of BizTalk use another concept called 'marking transactions'. This is simply a way that transactions across databases get flagged as being part of the same transaction. It is a feature of SQL 2000 itself.
To help with setting up these kind of backups a sample scheduled task is created for you during the install of BizTalk 'Backup BizTalk Server'. By default it might not work because it still needs to be configured (default values like backup path must be filled in)
It contains 3 steps:
1. A full backup that needs to run only something like once a week or so
2. A MarkAndBackupLog step (which does all the magic...)
3. And a 'Clear Backup History' step.
This SQL job is just a sample and could be use to create a proper schedule to backup BizTalk properly. The backup files created on disk can then be backed up using any normal disk backup tool.
Restoring these backups must be done like this:
1. Restore all BizTalk databases using the last full backup with the NORECOVERY option.
2. Then restore all log backups also using the NORECOVERY option except for the very last log backup - if there is only one log backup then skip this step)
3. Lastly using both the RECOVERY and STOPATMARK options restore the very last log backup.
This will ensure that only successful and complete transactions across all the databases gets restored.
Ok, now and go and backup your BizTalk databases properly and have fun!
[Update: for more details on what 'marking transactions' is look up 'marking transactions' in SQL BOL - books on line]
[Update: If for any reason some of the BizTalk databases are marked 'Simple' (recovery options) the backup routine will fail. Been there, got burned...]
I've been wondering if there were other people that also have a passion for stories in the sci-fi genre. I've tried my hand in writing some books and know it’s not exactly 'easy' since there are so many different things that different people like and dislike.
Even if you can create or think of a good fictional story it is not that easy to tell it to others. The way it is told, type of language used and other extras can make even a good story a flop. Therefore it is usually better to have people interested in that type of story to test-read it – something I’m looking for.
There might be others with the same ideas that also have the same problems. If that is the case I would like to hear from you. Perhaps we can set up some network of people that wants to join in an idea like this.
The sci-fi genre is actually very diverse. For me personally I prefer sci-fi that is related to space, futuristic technology and wars.
There is another aspect that I think could help such a network or club. Getting together and watching or listening to existing sci-fi and enjoying it as a group can also be fun and helps to build the group’s identity.
If there are others that are keen on such a ‘club’ or if you know someone else that might be interested please contact me and we can see how and what we can do about it