Virtualisation, data networking, enterprise storage, security - and Microsoft SQL Server. The same topics crop up time and again as reader faves in The Reg Library. So here are three of the most popular papers concerned with one aspect of SQL Server or another from the Reg Library. SQL Server many-to-one protection This paper …
Understanding of Named Instances
"Named instances provide complete database isolation while allowing consolidation onto the same server. But it is a bitch for back-ups. Each instance must be maintained separately from the other instances on that server"
Have you missed the point named instances entirely? Of course you have to maintain them separately, that's the whole point! Each instance isn't just a isolated session of a single installation of SQL, it's a completely separate installation of SQL. You could have multiple identical instances, or you could have each of them running with a different version, 7, 2000, 2005, 2008, or even different service packs. Server\Instance1 and Server\Instance2 are in no way shape or form connected to one another, other than they both reside on the same server, and as such have to be treated, backed up and patched accordingly.
I'd be concerned about anyone happy to just role out a patch / service pack to multiple instances at the same time in a production environment, rather than properly installing and testing them individually.
"Generating up to one megabyte of data per second, ..... 2-3 terabytes per year"
Those figures don't really stand up to close scrutiny, do they?
@Dave & kindaian
jeez, you've never had to record data in any kind of experiment have you?
thats one megabyte per second *whilst the engine is running*... so that's 2 to 3 million seconds of running a year, perfectly reasonable (remember there are two cars and 16-18 races a season each race lasting 1h 30 or so ... so just short of 200,000 seconds of racing each year => 200GB of *race* data, the testing volume will be much higher than that of course and it looks like 10-15 times to get to 2-3 terabytes)
why record the temperature of the garage the car is parked in for forty or fifty hours over the weekend via the very strange proxy of the temperature of the engine cooling system.... at best a very lagging indicator.
equally you can slot more storage when the engine's are turned off and thus no data is incoming... you know like when you take your car to the garage, they'll service it whilst it's not running, not whilst you're half way down the M1 doing 70 in the outside lane....
NB filestream in SQLServer uses the database to store pointers to real file system files... no need to take the database down when you add more storage to the SAN now is there?
mine's the one with the hat of pendantry in the pocket