Pod::Manual was born a little bit more than three years ago, and kind of lingered in alpha-land ever since. But now, I had the opportunity to return to the project and do terrible things to it. The code is even more alpha than it was before, and it’s now in a post-hack shamble, but at least it has been moosified and (or so I hope) pushed in the right direction.

Avoiding the Perfect Storm

Many companies become accustom to lags in performance or even accept outages as normal to their day to day business due to poorly performing database environments. It’s what I refer to as the plague of the database industry and the constant frustration of DBA’s everywhere. Until these lags and outages become huge storms and are impossible to ignore, it is commonly tolerated. How do environments end up in this situation?

Give Me Reason, Take Me Higher

Pythian, a cluster of passionate DBAs, gives freedom to their DBAs to act. Here, with many companies, and with many databases of a different nature with varying requirements the DBAs are kept on fire. DBAs find reasons to come to their job every day, and when they do and learn new things every day, they rise to new heights. With new heights comes sense of achievements which generates happiness and when the DBAs are happy, databases under them touch new heights of mirth and perform beautifully. That is what Pythian is all about in my opinion.


Right now, Galuga has a widget that lists my CPAN distributions. But it’s a boring old static affair that is updated manually. Surely in this age of the Web 2.0, I can do better than that. My first instinct that to go straight for my CPAN author page and extract the information off the HTML

Getting Around Expiration Dates via Reincarnation (and Catalyst)

Web applications typically have a bunch of static files that almost never change. For all but the simplest apps, it’s usually a good idea to let the browser know that it can cache and reuse those files, so that we can all save a little bit of bandwidth and get things moving a wee bit faster. For that, we have the HTTP Expires header. Have a look.

11G R2 Cluster: AVOID using sqlplus & lsnrctl for Oracle

For last few months I was part of the Pythian’s team helping implement Oracle 11gR2 Clusters for different Oracle customers. All the implementations had different requirements and configurations, however, in all cases, the client’s DBAs made the same mistake over and over again. They used sqlplus and lsnrctl utilities to manage (start/stop) databases and listeners. This is totally wrong in the 11gR2 Cluster world. The following commands are just few examples on how you should start/stop Oracle processes

DBD::Oracle and Oracle 11gR2 – Battle of Bits

11gR2, lib32 directory no longer exists and 32 bit libraries are no longer provided. Which means that there is no way to use 32 bit Perl to connect to Oracle. BTW. This applies to other 32 bit clients as well. I’ve heard that SAP can’t support 11gR2 for a similar reason. What do we do? Here are the options.

Page 90 of 240« First...102030...8889909192...100110120...Last »