Security – Best practices for SQL Server audit trail

This is the sort of thing that DTS/SSIS is commonly used for. One major warning, though, is that the out-of-box components for loading to an Oracle database are unacceptably slow for row counts over about 1000 (less if you need really fast loads). If I were doing this on a regular basis (every hour or so, for example), I'd probably use SSIS to create a package, but my load to Oracle would be through SQL*Loader (it's a ton faster). As for the data integrity piece, it's not too difficult to use SSIS to do the verification of the data, assuming you have relatively straightforward foreign key relationships. If you have extremely complex integrity constraints, you'll be better off creating a stored proc on the destination DB that you call with the SQL Server data after loading it into a staging table (this is the approach that Oracle EBS uses, so it's almost got to be a best practice by definition).

• Use passwords that are not composed of common words or names. Dictionary attacks use dictionaries with millions of words and are very quick.

• Use long passwords. I tend to use passphrases. I pick a phrase, sentence or rhyme and find some way to use a fair number of non alpha-numeric characters so that my words are not dictionary words.

• Do not use the same password for multiple login services. Take some time to come up with a formula for picking passphrases. This allows you to use many different passwords that, if forgotten, you may be able to recreate with some trial and error.

• If you have to, by all means write a good, long, secure password down and hide it somewhere. That at least is better than using a weak password that is easier to remember.

• If the above suggestions prove unmanageable, use a password manager with a long secure password and then use random character passwords for everything else. Carry the password manager around with you on an encrypted USB flash drive (backed up of course).