Here’s a quick note, written and some strange time in (my) morning in Hong Kong airport as I wait for my next flight – all spelling, grammar, and factual errors will be attributed to jet-lag or something.
And a happy new year to my Chinese readers.
You all know that having more than 255 columns in a table is a Bad Thing ™ – and surprisingly you don’t even have to get to 255 to hit the first bad thing about wide tables. If you’ve ever wondered what sorts of problems you can have, here are a few:
On April 1 2015, I’ll start working for the Accenture Enkitec Group. No, this is not a joke for the Fool’s day and I can’t still believe it. Why?, because:
There's nothing worse than having a nefarious digital worm weaving in and out of your servers, stealing information from enterprise applications and databases under the guise of a legitimate file.
An open source mentality
Unfortunately, malware is engineered much like how open source software is: A community of developers (in this case, hackers) are given access to a machine where a program can be continuously updated and refined.
Hi, welcome to RDX! Red Hat Enterprise Linux 7.1 may still be in beta, but some of its features are definitely worth noting.
V3 noted that IBM has made the Power8 version of RHEL 7.1 available via its Power Development Platform. Support for Power8 was implemented through the little endian instruction format. System administrators can download 7.1 for testing purposes.
We saw in my last blog how to install the SQL Server plugin for Nagios.In this new blog, I will explain:
There are many articles explaining how to migrate database from file system into ASM. You could use RMAN to create an image copy of the database into ASM and switch to the database copy, restore database from backup sets into ASM or create duplicate database.
All of these RMAN features are available on Oracle versions before 12c.
In this post I will use slightly different approach - using online relocation of data files into ASM.
As a MySQL DBA I already know the data changes that happen on my system. I have logs for that.
However, it’s a common problem that several years into the life of an application, the current developers won’t know where in the codebase queries come from. It’s often hard for them to find the location in the code if queries are formed dynamically; the pattern I show them to optimize doesn’t match anything in the code.
I stumbled on a trick a couple years ago that has been invaluable in tracking down these problematic queries: query comments.
Here’s an example:
Except a few special cases, optimizing SQL is about minimizing I/O. And by “I/O” we normally mean “physical I/O”, because everybody knows that logical I/O (LIO) is much, much faster. But how much faster exactly? For a long time, this question has been bothering me. It looks like there has been little research in this area. Basically the only thorough investigation I managed to find on the subject was one by Cary Millsap and co-authors.