As many may have noticed, PostgresOnline.com has been down for the past week or so and probably is still not reachable from many parts of the world since our DNS server was also taken down as a result of a Distributed Denial of Service (DDOS) attack instigated by an Activision Call of Duty Game exploit that turned thousands of Call of Duty game servers into Zombies launching an attack on us.

We have a small confession to make. One of the businesses we co-own is an e-Commerce site that sells condoms. You never know how people will react when you say that in mixed company so we only mention it in closer company. Some people are glad we are in a business protecting against venereal diseases or unwanted pregnancies and some feel strongly we are violating a mother nature creed of conduct. WowCondoms was the site that was under attack on a UDP port and we are not sure if it was a malicious intent or not since the root instigator has not been found yet. The attack was higher up from our servers so it knocked our ISP who in turn blamed us for their outage. We never saw the traffic.

The tragic thing is that it can happen to any site and does all the time. It really hit home when it happened to us.

Details of our fight are described here: WowCondoms plugs hole in Activision's Call of Duty Game Servers

Many developers have argued persuasively that each database developer in a team needs to work as sole user of a dedicated database-development environment whilst creating or updating databases. I'm not so sure. Are we in danger of trying to change database development practices to try to cure a problem that is far easier to solve by proper system design?

We all appreciate that, in general, XML documents or fragments are held in strings as text markup. In SQL Server, XML variables and columns are instead tokenised to allow rapid access to the data within. This is fine, but can cause some odd problems, auch as 'entitization'. What, also, do you do if you need to preserve the formatting? As usual Rob Sheldon comes to our aid.

The arrival of the (MAX) data types in SQL Server 2005 were one of the most popular feature for the database developer. At the time, there was a lot of discussion as to whether this freedom from having to specify string length came at a cost. Rob attempts to give a final answer as to any down-side.

Occasionally, when you install identical databases on two different SQL Server instances, they will behave in surprisingly different ways. Why? Most likely, it is down to different configuration settings. There are around seventy of these settings and the DBA needs to be aware of the effect that many of them have. Brad McGehee explains them all in enough detail to help with most common configuration problems, and suggests some best practices.

PostgreSQL has aggregate functions called bool_and and bool_or which it's had for as far back as I can remember. What do they do? given rows of premises (things that resolve to booleans), bool_and will return true if all of the premises are true. Similarly bool_or will return true if any of the premises in the set of rows is true. What if however your boolean expressions are not in rows, but instead passed in as a sequence of arbitrary statements of questionable fact. We want a function like bool_or or bool_and that takes an arbitrary number of boolean arguments. Are there functions that fit the bill. Indeed there are, but they don't scream out and say I work with booleans because they fit into a class of function we discussed in The wonders of Any Element and that also happen to be variadic functions. These are none other than greatest and least and they are old timer functions that you can find in most versions of PostgreSQL. We'll demonstrate how to use all 4 with booleans in this article. It must be said that greatest and least are much more useful when applied to other data types like dates and numbers, but we were amused at the parallel with booleans.

Side note: we've started to write our book on PostgreSQL that will be published by O'Reilly. We hope to finish this book within the next 5-7 months but have preliminary e-Book drafts before then for early purchasers to scan. The focus of the book will be PostgreSQL 9.1 with some highlights the upcoming PostgreSQL 9.2. Of course oldie but goodie topics are in the book too. It's a thrill to be writing again.
Continue reading "True or False every which way"

If you just assume that your application's slowness is the fault of the database, then that is a quick route to a smug DBA if it later turns out you’re wrong. Far better to know for sure how much of your applications time is spent waiting around for the database to do something, and how many round-trips to and from the database it makes.

ConcurrentQueue is, like ConcurrentStack, a lockless collection, in that it is implemented without using any locks at all. However, the semantics required for a queue impose a quite different approach; unlike ConcurrentStack, which has a single point of concurrent contention, a queue can be changed at both the head and tail.

We're currently trying to build a service that lets developers silently update their application. We want desktop developers to enjoy all the same advantages as those who code for web. Desktop software shouldn't become a second class citizen just because it's too slow to adapt.

Over the next few months, we'll be asking various well-known DBAs to describe their worst disaster caused by a mistake they made. To kick off the series, we asked Phil Factor to confess. He came up with a classic: The mistaken belief that a backup WITH CHECKSUM guaranteed a good backup that could be restored, and the ensuing disaster.

At last, we’ve woken up to the worrying fact that there just aren’t enough good programmers to go around. Instead of aiming to get a generation of students interested in building their own software, education has instead been compelled by national governments to focus on stultifying vocational work geared to office skills.

Static code analysis is used a lot by application programmers, but there have been surprisingly few tools for SQL development that perform a function analogous to Resharper, dotTest, or CodeRush. Wouldn't it be great to have something that can indicate where there are code-smells, lapses from best practice and so on, in your Database code? Now there is.

Probably the most common question that the Red Gate developer tools support gets is "Does your X work with Y?" where X is your bit of software and Y is a bit of software made by a different company. This is probably the least answerable question in the known universe.

Chuck Moore is still the radical thinker of Information Technology, After an astonishing career designing languages (e.g. FORTH), browser-based computers, CAD systems and CPUs, he is now energetically designing extremely low-powered 'green' multi-processor chips for embedded systems. Behind everything he does is a radical message: 'Embrace the entire problem, Keep it simple'.

One of the more popular counters used by DBAs to monitor SQL Server performance, the Buffer Cache Hit Ratio, is useless as a predictor of imminent performance problems. Worse, it can be misleading. Jonathan Kehayias demonstrates this convincingly with some simple tests.

I thought I would give an roundup of how the lean startup experiments in our .NET division at RedGate have been progressing. As you can expect, there's been some good aspects and some bad aspects.

The extent of malicious hacking on the internet, in pursuit of political or economic advantage, crime or just plain mischief, threatens to escalate the cost of even basic IT infrastructure. In the emerging economies, organised hacking is now beginning to impede economic growth so much that organised counter-measures are now required. Our Pakistan correspondent describes the problem there, and suggests some solutions.

Developing a Sharepoint application would have all the fun of a video game, if only you had infinite lives. Dangers lurk hidden out there which, if you run into them, can be a blow to your project and waste a great deal of time. Damon gives just one example of a poisoned dagger in the game of Sharepoint Development: The Item Event Receiver.

We asked Buck Woody to come up with his favourite 'Cloud' Howlers. After 'Howler' monkeys, we are faced with Howler letters. Buck dreams of sending Howler letters to the folks who dreamed up the marketing hype around 'cloud' services, who misunderstand services, who don't prepares applications for distributed environments and so on.

The relational model was devised long before computer hardware was able to support an RDBMS that could deliver, without performance deficit, a fully normalized database. Now, with reliable SSDs falling in price, we can reap the benefits, instead of getting distracted by NOSQL with its doubtful compromise of 'eventual consistency'.