I did the same some time ago on all our servers. No problems. Just to be sure there will be no issues, I queried sysprocesses table periodically for a week...

Just a couple of thoughts of mine.

The bigger physical size of transaction log file shouldn't mean longer transaction log backup time because only actual transaction activity is stored in backup...

If you can afford a server downtime it would be worthwhile to run sqliostress utility as sushila suggested. In addition to the mentioned article you can see these:

http://support.microsoft.com/default.aspx?scid=kb;en-us;826433

As it seems that you expose yourself to a risk of losing data entered/modified during the optimization job by not taking log backups at that time, you might choose a bit different...

Have you found a solution to your problem? I don't have much time but I put together this simple script that works for me. Value -1 in sysfiles.maxsize indicates that...

I don't know any other causes of the problem but someone else here might do. On install, all system dbs have the same collation that you specify in setup, personally I would...

Basically collation is a set of information how character data is stored and treated in db. Most notably code page, sort order and case-sensitivity. You can find a lot of...

My first thought is that you have different collation of master and model/tempdb databases.

Can you run these 3 commands

select databasepropertyex('master','collation')

select databasepropertyex('model','collation')

select databasepropertyex('tempdb','collation')

and post results?

IMHO, you shouldn't run into problems with object ownerwhip using sp_change_users_login proc at all. Object owner is identified by user id in sysobjects table which doesn't change during this process. This is SIDs mismatch issue.

Don't bother yourself with changes to system catalog, it's not necessary in this case. Your problem is called orphaned user - mismatch between login and user in system tables. You can use...

Actually, info about backup devices is stored in master db. Check it as well.

You can use RESTORE HEADERONLY FROM 'backup_device'

command which will give you similar info.

The information is stored in msdb database, so it would be worthwhile to check its collation as well:

select databasepropertyex('msdb','collation')

What...

Under simple recovery model, you don't need to worry about transaction log growth much because it gets truncated automatically at every checkpoint. Thus only large transaction can cause your transaction log to...

1. IMHO (without knowing further details) by doing this they might ask for a trouble in the event of a failure, because file system backups of sql server databases should...

Actually, you shouldn't shrink transaction logs at all. Shrinking has considerable overhead, which can be avoided and can lead to fragmentation of database files on file system. The best way...