Platform, Database and Storage Topics
I’ve been stranded in Europe for 4 days and the situation persists! Needless to say I haven’t been thinking that much about blogging 😦
I do have a post nearly ready to go about booting 4s48c Opteron 6100 systems with _enable_NUMA_support set to TRUE. There are some caveats, and some very significant benefits as well. I’ll post that as soon as my situation improves…
By the way, no I have not taken the time to learn the pronunciation of the Volcano. I’ve opted for the military moniker: E15. 🙂
Earlier this week I was taking a gander at what in-bound traffic my site was getting. One referrer stood out in my initial perusal. While I don’t know Gavin Soorma, just a bit of reading on his blog led me to conclude that this site is a jewel worth visiting:
In my on-going series about Oracle Database 11g configuration for NUMA systems I’ve spoken of the enabling parameter and how it changed from _enable_NUMA_optimization (11.1) to _enable_NUMA_support (11.2). For convenience sake I’ll point to the other two posts in the series for folks that care to catch up.
What does AMD Opteron 6100 (Magny-Cours) have to do with my on-going series on enabling/disabling NUMA features in Oracle Database? That’s a good question. However, wouldn’t it be premature to just presume each of these 12-core processors is a NUMA node?
The AMD Opteron 6100 is a Multi-Chip Module (MCM). The “package” is two hex-core processors essentially “glued” together and placed into a socket. Each die has its own memory controller (hint, hint). I wonder what the Operating System sees in the case of a 4-socket server? Let’s take a peek.
The following is output from the numactl(8) command on a 4s48c Opteron 6100 (G34)-based server:
# numactl --hardware available: 8 nodes (0-7) node 0 size: 8060 MB node 0 free: 7152 MB node 1 size: 16160 MB node 1 free: 16007 MB node 2 size: 8080 MB node 2 free: 8052 MB node 3 size: 16160 MB node 3 free: 15512 MB node 4 size: 8080 MB node 4 free: 8063 MB node 5 size: 16160 MB node 5 free: 15974 MB node 6 size: 8080 MB node 6 free: 8051 MB node 7 size: 16160 MB node 7 free: 15519 MB node distances: node 0 1 2 3 4 5 6 7 0: 10 16 16 22 16 22 16 22 1: 16 10 22 16 16 22 22 16 2: 16 22 10 16 16 16 16 16 3: 22 16 16 10 16 16 22 22 4: 16 16 16 16 10 16 16 22 5: 22 22 16 16 16 10 22 16 6: 16 22 16 22 16 22 10 16 7: 22 16 16 22 22 16 16 10
Heft
It wasn’t that long ago that an 8-node NUMA system was so large that a fork lift was necessary to move it about (think Sequent, SGI, DG, DEC etc). Even much more recent 8-socket (thus 8 NUMA nodes) servers were a 2-man lift and quite large (e.g., 7U HP Proliant DL785). These days, however, an 8-node NUMA system like the AMD Opteron 6100 (G34) comes in a 2U package!
Is it time yet to stop thinking that NUMA is niche technology?
I’ll blog soon about booting Oracle to test NUMA optimizations on these 8-node servers.
I received several emails from readers reporting that AnandTech moved the page I referred to in yesterday’s post about Intel Xeon 5600 (Westmere EP) / AMD Opteron 6100 (Magny-Cours). I fixed the link on that post so feel free to click through and get to the article there if you wish.
In May 2009 I made a blog entry entitled You Buy a NUMA System, Oracle Says Disable NUMA! What Gives? Part II. There had not yet been a Part I but as I pointed out in that post I would loop back and make Part I. Here it is. Better late than never.
Background
I originally planned to use Part I to stroll down memory lane (back to 1995) with a story about the then VP of Oracle RDBMS Development’s initial impression about the Sequent DYNIX/ptx NUMA API during a session where we presented it and how it would be beneficial to code to NUMA APIs sooner rather than later. We were mixing vision with the specific need of our port to be honest.
We were the first to have a production NUMA API to which Oracle could port and we were quite a bit sooner to the whole NUMA trend than anyone else. Our’s was the first production NUMA system.
Now, this VP is no longer at Oracle but the (redacted) response was, “Why would we want to use any of this ^#$%.” We (me and the three others presenting the API) were caught off guard. However, we all knew that the question was a really good question. There were still good companies making really tight, high-end SMPs with uniform memory. Just because we (Sequent) had to move into NUMA architecture didn’t mean we were blind to the reality around us. However, one thing we knew for sure—all systems in the future would have NUMA attributes of varying levels. All our competition was either in varying stages of denial or doing what I like to refer to as “Poo-pooh it while you do it.” All the major players eventually came out with NUMA systems. Some sooner, some later and the others died trying.
That takes us to Commodity NUMA and the new purpose of this “Part I” post.
Before I say a word about this Part I I’d like to point out that the concepts in Part II are of a “must-know” variety unless you relinquish your computing power to some sort of hosted facility where you don’t have the luxury of caring about the architecture upon which you run Oracle Database.
Part II was about the different types of NUMA (historical and present) and such knowledge will help you if you find yourself in a troubling performance situation that relates to NUMA. NUMA is commodity, as I point out, and we have to come to grips with that.
What Is He Blogging About?
The current state of commodity NUMA is very peculiar. These Commodity NUMA Implementations (CNI) systems are so tightly coupled that most folks don’t even realize they are running on a NUMA system. In fact, let me go out on a ledge. I assert that nobody is configuring Oracle Database 11g Release 2 with NUMA optimizations in spite of the fact that they are on a NUMA box (e.g., Nehalem EP, AMD Opterton). The reason I believe this is because the init.ora parameter to invoke Oracle NUMA awareness changed names from 11gR1 to 11gR2 as per My Oracle Support note 864633.1. The parameter changed from _enable_NUMA_optimization to enable_NUMA_support. I know nobody is setting this because if they had I can almost guarantee they would have googled for problems. Allow me to explain.
If Nobody is Googling It, Nobody is Doing It
Anyone who tests _enable_NUMA_support as per My Oracle Support note 864633.1 will likely experience the sorts of problems that I detail later in this post. But first, let’s see what they would get from google when they search for _enable_NUMA_support:
Yes, just as I thought…Google found nothing. But what is my point? My point is two-fold. First, I happen to know that Nehalem EP with QPI and Opteron with AMD HyperTransport are such good technologies that you really don’t have to care that much about NUMA software optimizations. At least to this point of the game. Reading M.O.S note 1053332.1 (regards disabling Linux NUMA support for Oracle Database Machine hosts) sort of drives that point home. However, saying you don’t need to care about NUMA doesn’t mean you shouldn’t experiment. How can anyone say that setting _enable_NUMA_support is a total placebo in all cases? One can’t prove a negative.
If you dare, trust me when I say that an understanding of NUMA will be as essential in the next 10 years as understanding SMP (parallelism and concurrency) was in the last 20 years. OK, off my soapbox.
Some Lessons in Enabling Oracle NUMA Optimizations with Oracle Database 11g Release 2
This section of the blog aims to point out that even when you think you might have tested Oracle NUMA optimizations there is a chance you didn’t. You have to know the way to ensure you have NUMA optimizations in play. Why? Well, if the configuration is not right for enabling NUMA features, Oracle Database will simply ignore you. Consider the following session where I demonstrate the following:
Note, in spite of event #3, the alert log will not report anything to you about what went wrong.
SQL> SQL> !numactl --hardware available: 2 nodes (0-1) node 0 size: 36317 MB node 0 free: 31761 MB node 1 size: 36360 MB node 1 free: 35425 MB node distances: node 0 1 0: 10 21 1: 21 10 SQL> startup pfile=./p4.ora ORACLE instance started. Total System Global Area 5746786304 bytes Fixed Size 2213216 bytes Variable Size 1207962272 bytes Database Buffers 4294967296 bytes Redo Buffers 241643520 bytes Database mounted. Database opened. SQL> show parameter _enable_NUMA_support NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ _enable_NUMA_support boolean FALSE SQL> SQL> !grep _enable_NUMA_support ./p4.ora _enable_NUMA_support=TRUE
OK, so the instance is up and the parameter was reverted, what does the IPC shared memory segment look like?
SQL> !ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 644 72 2 0x00000000 32769 root 644 16384 2 0x00000000 65538 root 644 280 2 0xed304ac0 229380 oracle 660 4096 0 0x7393f7f4 1179653 oracle 660 5773459456 35 0x00000000 393223 oracle 644 790528 5 dest 0x00000000 425992 oracle 644 790528 5 dest 0x00000000 458761 oracle 644 790528 5 dest
Right, so I have no NUMA placement of the buffer pool. On Linux, Oracle must create multiple segments and allocate them on specific NUMA nodes (memory hierarchies). It was a little simpler for the first NUMA-aware port of Oracle (Sequent) since the APIs allowed for the creation of a single shared memory segment with regions of the segment placed onto different memories. Ho Hum.
What Went Wrong
Oracle could not find the libnuma.so it wanted to link with dlopen():
$ grep libnuma /tmp/strace.out | grep ENOENT | head 14626 open("/usr/lib64/libnuma.so", O_RDONLY) = -1 ENOENT (No such file or directory) 14627 open("/usr/lib64/libnuma.so", O_RDONLY) = -1 ENOENT (No such file or directory)
So I create the necessary symbolic link and subsequently boot the instance and inspect the shared memory segments. Here I see that I have a ~1GB segment for the variable SGA components and my buffer pool has been segmented into two roughly 2.3 GB segments.
# ls -l /usr/*64*/*numa* lrwxrwxrwx 1 root root 23 Mar 17 09:25 /usr/lib64/libnuma.so -> /usr/lib64/libnuma.so.1 -rwxr-xr-x 1 root root 21752 Jul 7 2009 /usr/lib64/libnuma.so.1 SQL> show parameter db_cache_size NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_cache_size big integer 4G SQL> show parameter NUMA_support NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ _enable_NUMA_support boolean TRUE SQL> !ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 644 72 2 0x00000000 32769 root 644 16384 2 0x00000000 65538 root 644 280 2 0xed304ac0 229380 oracle 660 4096 0 0x00000000 2719749 oracle 660 1006632960 35 0x00000000 2752518 oracle 660 2483027968 35 0x00000000 393223 oracle 644 790528 6 dest 0x00000000 425992 oracle 644 790528 6 dest 0x00000000 458761 oracle 644 790528 6 dest 0x00000000 2785290 oracle 660 2281701376 35 0x7393f7f4 2818059 oracle 660 2097152 35
So there I have an SGA successfully created with _enable_NUMA_support set to TRUE. But, what strings appear in the alert log? Well, I’ll blog that soon because it leads me to other content.
Some of one and none of the other actually…
I’ve received a couple of emails wondering what’s happened to my blogging. No worries, just really busy. I’ve been putting some (very) interesting hardware through the performance wringer lately.
What, doesn’t everyone’s performance sandbox look like the following?
# mpstat -P ALL 5 05:14:24 PM all 91.99 0.00 8.01 0.00 0.00 0.00 0.00 0.00 1117.00 05:14:24 PM 0 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 1000.33 05:14:24 PM 1 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 2 92.67 0.00 7.33 0.00 0.00 0.00 0.00 0.00 58.00 05:14:24 PM 3 92.98 0.00 7.02 0.00 0.00 0.00 0.00 0.00 0.67 05:14:24 PM 4 94.00 0.00 6.00 0.00 0.00 0.00 0.00 0.00 5.00 05:14:24 PM 5 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 6 91.36 0.00 8.31 0.00 0.00 0.33 0.00 0.00 26.67 05:14:24 PM 7 91.36 0.00 8.64 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 8 91.97 0.00 8.03 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 9 91.69 0.00 8.31 0.00 0.00 0.00 0.00 0.00 17.67 05:14:24 PM 10 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 5.33 05:14:24 PM 11 92.03 0.00 7.97 0.00 0.00 0.00 0.00 0.00 3.33 05:14:24 PM 12 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 13 91.03 0.00 8.97 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 14 92.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 15 91.30 0.00 8.70 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 16 92.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 17 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 18 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 19 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 20 91.33 0.00 8.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 21 92.67 0.00 7.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 22 91.97 0.00 8.03 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 23 92.03 0.00 7.97 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 24 92.98 0.00 7.02 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 25 92.03 0.00 7.97 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 26 92.33 0.00 7.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 27 92.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 28 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 29 93.00 0.00 7.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 30 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 31 91.33 0.00 8.67 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 32 91.97 0.00 8.03 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 33 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 34 92.69 0.00 7.31 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 35 91.00 0.00 9.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 36 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 37 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 38 91.36 0.00 8.64 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 39 92.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 40 93.00 0.00 7.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 41 91.36 0.00 8.64 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 42 91.03 0.00 8.97 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 43 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 44 91.00 0.00 9.00 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 45 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 46 91.67 0.00 8.33 0.00 0.00 0.00 0.00 0.00 0.00 05:14:24 PM 47 91.33 0.00 8.67 0.00 0.00 0.00 0.00 0.00 0.00
This is just a quick blog entry to point out that I’ve renamed one of my index pages to include categorization of Oracle Database 11g Database File System (DBFS) related topics. The newly-named page can be found at the following URL:
Kevin Closson Blog: DBFS / CFS / NFS / ASM Related Topics
The freshly indexed posts I’ve added to that page are:
I routinely get asked which blogs I frequently read. I list some of them in my blogroll. It just dawned on me that even though I have Tim Hall’s ORACLE-BASE blog listed in my blogroll I should make a special note that Tim’s blog is a really, really helpful resource.
There are a lot of blogs I read that I don’t mention. For obvious reasons I don’t currently want to link to Oracle’s competitors’ blogs. I wouldn’t want them to get a any boost in readership for free now, would I?
One tricky thing to figure out is how to treat Oracle’s “coopetitors” if you will. Now that Oracle owns a hardware company the lines are really fuzzy. I think it use to be that only Microsoft fell squarely into both the competitor and (quasi) partner space since both Microsoft and Oracle were software companies and both brought RDBMS products to market but neither were hardware companies (forgetting for the moment the Xbox). I refer to Microsoft as (quasi) partner of Oracle because Oracle offers products on Windows and unless I’m particularly naïve Microsoft takes no position directly against customers running Oracle on Windows. Indeed, others in the same scenario have played the “if you load product XYZ we won’t support your OS” trick. Now that Oracle is a hardware and software company I have to get direction from corporate on what acronyms (e.g., IBM, HP, etc), when spoken, will find me getting my mouth washed out with soap.
I’m finding that one of the more confusing aspects of Oracle Database 11g Database File System (DBFS) for folks to understand is the difference between access and administration permissions.
The Oracle Databse 11g Database File System (DBFS) documentation discusses the “fuse” group, the allow_other DBFS mount option and the /etc/fuse.conf file but all this information doesn’t draw a clear distinction between administrative permissions and access permissions.
If the allow_other mount option is passed—when using dbfs_client to mount a file system—then other, ordinary Linux users can access file system contents as per the normal Linux file system permissions. Consider the following example. I’ll show that I have a DBFS file system mounted at /data. Next, as root, I’ll create a file called joe.txt and then modify its ownership to joe and group joe:
# mount | grep /data dbfs on /data type fuse (rw,nosuid,nodev,max_read=1048576,default_permissions,allow_other,user=oracle) # ls -ld /data /data/FS1 /data/FS1/joe.txt drwxr-xr-x 4 root root 0 Feb 10 17:30 /data drwxrwxrwx 76 oracle dba 0 Feb 10 17:27 /data/FS1 -rw-r--r-- 1 joe joe 0 Feb 10 17:27 /data/FS1/joe.txt
Next, I’ll switch user (with login) to the user joe and list joe’s file. It is owned by joe and all directory hierarchy permissions back to /data permit joe’s access, so it should be no problem:
# su - joe $ $ id uid=1001(joe) gid=1005(joe) groups=1005(joe) $ ls -l /data/FS1/joe.txt ls: /data/FS1/joe.txt: Permission denied
OK, so something is obviously wrong. Yes, there is. It is a known bug (8976604) and there is a very simple work-around. I don’t like blogging about known bugs, but I think someone will likely find this via a Google search. Allow me to explain the work-around
The work-around for bug 8976604 is to supply to pass-through-fuse-options parameter at mount time. Consider the following example:
$ $ORACLE_HOME/bin/dbfs_client dbfs@ --pass-through-fuse-options -o allow_other,direct_io /data < /opt/oracle/dbfs/passwd.txt & [1] 2931 $ Password: $ su - joe Password: $ $ id uid=1001(joe) gid=1005(joe) groups=1005(joe)$ ls -l /data/FS1/joe.txt total 0 -rw-r--r-- 1 joe joe 0 Feb 10 17:27 /data/FS1/joe.txt
There, joe is happy now that he can see the file he owns.
I haven’t made a blog entry in about two weeks but that is not due to of lack of topics. I get a constant flow of email from readers with requested topics that they’d like to see covered in this blog.
I’m speaking at Hotsos Symposium 2010 next month and my presentation consists of a deep dive into a lot of the sorts of topics readers ask me to blog about. I’ve posted the abstract below. The abstract is also posted at the Hotsos Symposium 2010 speaker page.
According to the speaker schedule I’m presenting in a time slot adjacent to Tom Kyte’s session about PL/SQL. So, if you are one of the 3 or so people who, for one bizarre reason or another, decide not to see Tom, perhaps you can attend my session. We’ll all be able to stretch out as there will be plenty of room 🙂
Here’s the abstract:
Whether you call it “the two-thousands”, the “Ohs”, “The Naughties” or “The Aughts”, the first decade of this millennium is over and it ushered in a significant amount of new technology related to Oracle. Don’t be alarmed, this is not one of those worthless technical chronology presentations. After all, is there anyone who isn’t aware that the decade started with the introduction of Real Application Clusters—and thus the demise of the large, central server—and finished with Oracle acquiring Sun Microsystems? This presentation has nothing to do with any of that! In spite of how much technology has changed, we really do still seem to be stuck in the 1990s. The following is sample of some of the topics I’ll be diving into—deeply.
And, of course, I’ll be talking a bit about Oracle Exadata Storage Server and the Oracle Database Machine.
In my recent post entitled Oracle Database 11g Database File System (DBFS) Is Not A Popular Topic. Yet., I discussed how I use Google search terms as a way of monitoring what sorts of problems people are running into with new technology such as (DBFS).
This is part one in a series of posts where I’ll offer some tips regarding the more common DBFS-related problems one might encounter in early testing. The first I’ll tackle is “Transport endpoint is not connected.”
Error Text: Transport Endpoint is not connected.
This error string occurs when attempting to access a mounted DBFS file system. The error condition arises when there is no dbfs_client currently executing that is associated with the file system.
In the following boxes I’ll show two examples of how this error can be encountered. First, I’ll show that I have a DBFS file system mounted and that an attempt to change directories to the mount point results in “Transport endpoint is not connected”, such as:
$ mount | grep dbfs dbfs on /data type fuse (rw,nosuid,nodev,max_read=1048576,default_permissions,allow_other,user=oracle) $ cd /data -bash: cd: /data: Transport endpoint is not connected
A simple ps command shows there is no dbfs_client process executing:
$ ps -ef | grep dbfs_client oracle 1694 21941 0 09:49 pts/11 00:00:00 grep dbfs_client
This error condition is quite simple to rectify. You simply need to restart the dbfs_client process:
$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib $ export ORACLE_SID=DBFS1 $ $ ORACLE_HOME/bin/dbfs_client dbfs@ -o allow_root,direct_io /data < /opt/oracle/dbfs/passwd.txt & [1] 2501 $ fuse: bad mount point `/data': Transport endpoint is not connected
Sorry, I had to be sneaky in order to show one of the other conditions that raises the error. So, yes, to rectify this error condition you do have to restart dbfs_client, however, you need to first unmount the dead mount. You’ll see in the following box that I use fusermount –u to unmount and then execute dbfs_client and without any further action I can list the contents of the file system.
$ fusermount -u /data $ $ORACLE_HOME/bin/dbfs_client dbfs@ -o allow_root,direct_io /data < /opt/oracle/dbfs/passwd.txt & [1] 2931 $ Password: $ ls -l /data/FS1/TEST total 0 -rw-r--r-- 1 oracle oinstall 0 Dec 30 13:39 511b -rw-r--r-- 1 root root 0 Dec 30 13:40 test.out
Dead Mount, Living DBFS Instance.
If you look in the boxes above you’ll notice that dbfs_client was not executing (the real root of the problem) but the instance was running. Since dbfs_client is an OCI program all I had to do was kill it to create this scenario. If, however, you suffer this error while dbfs_client is executing then I recommend involving support because that would be a bug.
I find that keeping my finger on the blogosphere pulse is a good way to ascertain the adoption rate of new Oracle features such as Oracle Database 11g Database File System (DBFS). I see that Tim Hall has posted DBFS content in his typically excellent style!
I have a few posts on the topic of DBFS. Amongst the following list is a post (“Hidden Content?”) that will direct you to a webcast I delivered to IOUG Exadata Special Interest Group. The webcast is very informative because I introduce the concept of “injecting” files into the file system. Injecting? Yes, imagine transferring files into an Ext3 file system on a remote host without that file system even being mounted, anywhere! Cool technology and very efficient.
Google Search Terms
Another web aspect I monitor when it comes to new Oracle features is what search engine terms are being thrown at Google. For example, the following DBFS-related searches are likely search terms for folks that are testing the water with DBFS and/or suffering any problems getting it to work:
| Search Term | Hits |
| dbfs_client | 370 |
| dbfs_client +allow_root | 8 |
| dbfs_client +allow_other | 9 |
| DBFS +fusermount +oracle | 1100 |
| DBFS +direct_io | 246 |
| DBFS +exadata | 14,700 |
| –pass-through-fuse-options | 0 |
| “Transport endpoint is not connected” +DBFS | 0 |
| “fail to connect to database server” | 4 |
| “fail to connect to database server” +DBFS | 0 |
| dbfs_client +”fuse: failed to exec fusermount: Permission denied” | 0 |
| DBFS +”fuse: failed to exec fusermount: Permission denied” | 0 |
I aim to post a few blog entries with troubleshooting tips for some of the more common DBFS-related problems that customers might hit. The first entry I’ll make will cover the more common “Transport endpoint is not connected” error string that is returned under certain situations when trying to access DBFS mounts.
So, yes, the title of this post was a come-on. Oracle Database 11g Database File System is a new feature. It takes time for the blogosphere to catch up. But, as I’ve pointed out, there are good, trustworthy, bloggers posting content…like Tim Hall.
It’s been a while since I’ve posted an installment in my Little Things Doth Crabby Make series. While I’m not feeling particularly crabby, I have to admit that this one just got under my skin today.
Giga, Gibi, Giggly
I’m like most of you when it comes to computer capacity nomenclature. In spite of standards bodies I just can’t bring myself to think of a gigabyte as 10^9 bytes. The guys that sell memory still sell 2^30 bytes and processor caches are still sized in multiples of 2^20 bytes (a.k.a. old school Megabytes). But, according to standards bodies a gigabyte is 1000000000 bytes and what I refer to as a gigabyte is actually a gibibyte or 1073741824 bytes.
Network technology has always used the decimal nomenclature (e.g., megabit, gigabit) and since about the late 1990s hard drive manufactures switched to decimal. So, usually when we install something like a 600GB (gigabyte) drive and partition it we see 558 gibibytes such as this drive in the Sun Oracle Exadata Storage Server:
# cat /proc/partitions | grep sdh 8 112 585531392 sdh # bc -l bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. (585531392 * 1024) / (2^30) 558.40625000000000000000
Help Me Please, He’s Boring Me To Death!
I know, and I apologize. But let me just take one more moment of your time to show you what little thing hath crabby made. It’s all about the content in the following box. I tell dd(1) to write to disk exactly 1GB (a.k.a. “Kevin gigabyte”). That is, I want dd(1) to use a single call to LibC write to fill out 2^30 bytes. That works you know as long as you have address space and physical memory. Anyway, back to the topic. So, I set dd(1) out to create a 2^30 bytes, er, I mean 1GB file and so it did. But, it reported its success to me as if it was a real strict IEEE or networking sort of guy. In the box you’ll see that it reported it wrote 1.1GB and it did—1.1 gigabytes.
Sorry, I’m still boring you to death.
So the thing that made me crabby was the fact that I followed up the dd(1) command with an ls(1) command using the Linux –h option which, according to the manpage, reports sizes to me in “human readable” form. That’s OK with me since to me K,M,G are all powers of two and I’m a human. But I thought we were supposed to start rethinking our way to the decimal nomenclature. Hmmm. See for yourself:
# dd if=/dev/zero of=GB bs=1073741824 count=1 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB) copied, 2.4089 seconds, 446 MB/s # ls -lh GB -rw-r--r-- 1 root root 1.0G Jan 6 14:48 GB
Nah, that didn’t really make me that crabby. I do get tired of the decimal thing though. But worse than that is the schizophrenia dd(1) exhibits. The following is what really made me crabby:
$ dd if=/dev/zero of=1G bs=1G count=1 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB) copied, 1.19684 seconds, 897 MB/s
Now that is a good one! It’s sadly schizophrenic but entertaining.
2009 is drawing to a close so I just took a gander at the year-end search term statistics for my blog. It’s interesting to see the search terms that send readers to this blog. Some are surprising, others not so surprising. So, for trivial pursuit sake, the following list shows the top 50 search terms that resulted in a little over 30,000 click-throughs in CY2009. Quasi-interesting.
| Search Term | Visits |
| kevin closson | 5,612 |
| site:kevinclosson.wordpress.com direct i | 2,332 |
| cpuid linux | 2,258 |
| svr4 error: 25: inappropriate ioctl for | 1,693 |
| oracle exadata | 1,460 |
| linux cpuid | 1,279 |
| oracle orion | 1,276 |
| exadata | 1,221 |
| oracle nfs | 1,054 |
| oracle 10.2.0.4 | 970 |
| kevin closson blog | 872 |
| gridsql | 819 |
| oracle rhel5 | 704 |
| oracle alert log | 588 |
| ges: potential blocker | 564 |
| cpuid for linux | 515 |
| rhel5 oracle | 510 |
| prot-1: failed to initialize ocrconfig | 455 |
| sun flashfire | 440 |
| hugepages | 393 |
| oracle disk manager | 393 |
| closson wordpress | 382 |
| site:kevinclosson.wordpress.com direct i | 377 |
| linux cpu id | 371 |
| oracle nfs mount options | 319 |
| fibre channel | 311 |
| sql server on linux | 305 |
| 11g alert log | 304 |
| cpu id linux | 298 |
| nfs performance | 295 |
| os watcher | 285 |
| oracle secure files | 278 |
| sched_setaffinity | 278 |
| clusterdeconfig | 277 |
| t2000 oracle | 275 |
| orion oracle | 272 |
| selinux oracle | 267 |
| oracle numa | 262 |
| oracle blog | 262 |
| closson | 261 |
| crsd.bin | 256 |
| manly men | 250 |
| alert log location | 242 |
| 10.2.0.4 | 241 |
| solaris cp | 237 |
| shared appl_top | 217 |
| oracle t2000 | 217 |
| dbwr | 216 |
| oracle on nfs | 215 |
| oracle database 10.2.0.4 | 214 |
Click It
Recent Comments