Friday, April 29, 2005

Woeful Manly

For all those NRL (National Rugby League) fans... Tonites Friday night big game was a fizzer. I tried to watch Manly vs Brisbane and it was a shocker. Manly's mistakes (and an interesting referee decision early) made it painful to watch. The Manly fans from work will be spewing.

I enjoy watching a good game of league or any footy for that matter. It is no fun watching one side self-destruct.

Unfortunately the range of footy on free-to-air TV is now League or AFL. Premier League Soccer summary is gone and the summary show and shortened game for Super 12 union is gone. And noone bothers with NFL, NHL either. I want to now why my hard-earned tax dollars go to buying junk science programs on the ABC rather than showing some days old sports summary program from the NFL or NHL. At least the sport is reality, super-volcano and mock-documentaries are pure fiction.

Have Fun

SQL server 2005 or is that 2006

Database journal has a series of articles about SQLserver 2005 or codename Yukon.

It seems that a beta release is the standard practice, which allows the software company to gauge what features to spend the most time getting stable. Ahhh I am just an cynical DBA.

Considering security is a big issue for databases, the list of features apparently in SQLserver 2005 which look like low hanging fruit for those black hats out there is interesting. Peer-to-peer replication via http or https, with replication from Oracle databases!! hmmmm.
The mention that replication could be done over the internet using anything but https or more likely a hardcore VPN channel i.e. http makes the idea of "secure as default" an interesting statement.

There was no mention of fixing the locking mechanism where readers can block writers (by default) using a shared lock. Considering that the majority of database applications tend to be 90-95% reads, the idea of slowing down writes to tables, in an attempt to achieve read consistency is interesting.
You want transactions to write and get finished asap. Especially when trying to scale to handle larger number of transactions.
It depends on your application, but unless you must be sure that large read sees the data without changes, you should use the NOLOCK hint as required. This is definitely the case where the database is used more as a data repository than a well designed source of data and more importantly business rules.

For all the auto-tuning that Oracle 10G and SQLserver 2005 (apparently) can do. The big gainers, massive improvements in performance are in the design and the communication logic between the app and the database. Missing indexes and I/O balancing are simple, and shouldn't occur. If they do, it is easy to look the performance guru/hero. Nailing a database which won't scale, convincing the developer(s) that the comm logic is flawed and a better solution exists and the grand-daddy, showing where an extra table will remove redundancy and dodgy self-joins (Design) are much more fun.

More later.

Have Fun