dbi services Blog
Welcome to the dbi services Blog! This IT blog focuses on database, middleware, and OS technologies such as Oracle, Microsoft SQL Server & SharePoint, EMC Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on our blog postings.
A little bit less than one year ago, I wrote a blog about how to setup the Kerberos SSO on Liferay using Apache httpd as a front-end, Tomcat as a back-end and with auth_mod_kerb and mod_jk to transfer the information between these two components. Unfortunately, after some months, it seems that something changed either on the Liferay side or in the Apache side because the exact same configuration wasn't working anymore. I solved this issue (or at least applied a workaround) two or three months ago because I needed a working environment for some tests but until now, I didn't have the time to share my findings.
The result cache is very nice when base tables are static: get the result without any buffer get, without any join or sorts. But as soon as any DML occurs on one of the tables the result is based on, then result cache is invalidated. And cache misses are quite expensive. You can think of it as a materialized view in memory. But with materialized views, you can accept to see stale results in order to avoid frequent refreshes. Let's see how we can control stale results with undocumented options.
On the 2cnd of July the PostgreSQL Global Development Group released an alpha version of the upcoming PostgreSQL 9.5. The same day, Josh Berkus, another of those PostgreSQL core team members released a docker image for testing this alpha release. It's never been that easy to get started with PostgreSQL or testing new features.
As you know it is possible to install the ODA in a virtualized mode and to take avantages from all cores not licensed with Enterprise Edition for additional VMs.
The question is what could we do with it and which performances could we expect...
I posted a tweet with a link to a very old document - 20 years old - about 'internals of recovery'. It's a gem. All the complexity of the ACID mecanisms of Oracle are explained in a very simple way. It was written for Oracle 7.2 but it's incredible to see how much the basic things are still relevant today. Of course, there is a reason for that: the mecanisms of recovery are critical and must be stable. There is one more reason in my opinion: the Oracle RDBMS software was very well designed, then the basic structures designed 20 years ago are still able to cope with new features, and to scale with very large databases, through the versions and the years.
The cloud has been annouced, I want to try.