Posted by Luke Davies on Sep 30, 2009
Recently I was looking into a long-running statement and noticed a curious thing. One moment, I had just over 4 billion buffer gets, and the next I had around 2 million.
The statement was still processing and the number of physical reads was still rising.
I think the reason for this is that the internal place holder for this value is simply a 32-bit unsigned integer that has the largest number of 4294967295. But my version of Oracle is 64-bit; I thought that maybe it would use 64-bit integers.
So, beware that if you have had a statement running for some time, you cannot necessarily rely on the buffer_gets column in v$sql—it may be that it has run over the limit, been recycled, and is counting from zero again.
The evidence. Read the rest of this entry . . .
Posted by Nicklas Westerlund on Oct 6, 2008
Yesterday evening, a friend of mine had some issues with installing DBD::mysql, and asked if I had encountered the same issue. The problem, as the output from make test showed, was that certain symbols was missing:
# Tried to use 'DBD::mysql'.
# Error: Can't load '/Users/westerlund/src/perl/DBD-mysql-4.008/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/westerlund/src/perl/DBD-mysql-4.008/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Symbol not found: _is_prefix
Fair enough, this is related to a 64-bit issue with MySQL—at least with my Perl version, which is now:
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
Platform:
osname=darwin, osvers=9.5.0, archname=darwin-thread-multi-64int-2level
If you try to link to a x86_64 version of MySQL, then you get the above mentioned error. So, I downloaded an x86 version of MySQL and tried again. The output from perl Makefile.PL:
cflags (mysql_config) = -I/Users/westerlund/src/perl/mysql-5.1.28-rc-osx10.5-x86/include -g -Os -arch i386 -fno-common -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL
embedded (mysql_config) =
libs (mysql_config) = -L/Users/westerlund/src/perl/mysql-5.1.28-rc-osx10.5-x86/lib -lmysqlclient -lz -lm -lmygcc
mysql_config (Users choice) = /Users/westerlund/src/perl/mysql-5.1.28-rc-osx10.5-x86/bin/mysql_config
That looks all good and nice, the right paths, versions and everything. So I compiled it OK, but when running make test again: Read the rest of this entry . . .
Posted by Vasu Balla on Jul 15, 2008
Oracle R12 is certified to install on 64-bit Linux for X86_64 platforms. Yeah, I know that’s old news. The interesting part here is it’s not “pure” 64-bit software like the Oracle Database on Linux 64-bit: R12 is taking advantage of the OS’s capability to run 32-bit executables.
If we look at metalink note 416305.1, there is a big list of 32-bit RPMs in the pre-req packages list for R12 on 64-bit Linux. This is not something new — 11i on Solaris, HP-UX, and AIX also had the same behaviour.
11i doesn’t take advantage of 64-bit capabilities of the OS at full scale. It runs in 32-bit mode even on a 64-bit OS, as all its executables are 32-bit. One place where 11i does use the 64-bit feature is the “Memory Based Planner” program, which is part of the Advanced Supply Chain Planning (ASCP) module. Oracle shipped a 64-bit version of the program only for the Solaris, AIX, and HP-UX platforms, while the Linux version had just the 32-bit version. I have seen customers who added a Solaris Middle Tier to their Linux 11i instances just to run this 64-bit Planner program, spending all the dollars they saved with Linux middle tiers thus far, in consulting fees to add that extra Solaris middle tier node.
The good news for R12 customers is that, we don’t need a Solaris, AIX or HP-UX middle tier any more to run the 64-bit Planner program. Oracle has started shipping 64-bit Planner (MSONWL64.exe) for Linux 64-bit from version 12.0.3 onwards. Check Metalink note 254810.1 for details.
If you are a early adopter of R12 with a version earlier than 12.0.3, its time to patch up to 12.0.3 or 12.0.4. and migrate to the Linux 64-bit platform. This migration to Linux 64-bit should not be a big hassle, as it is binary-compatible with Linux 32-bit. I expect it be as simple as 1) copy, 2) relink, and 3) startup. I will, however, find out the exact method, and post here in the blog.
