Oracle has done a great job with the wait interface. It has given us the opportunity to profile the time spend in Oracle processes, by keeping track of CPU time and waits (which is time spend not running on CPU). With every new version Oracle has enhanced the wait interface, by making the waits more detailed. Tuning typically means trying to get rid of waits as much as possible.
Since the first patch for Oracle 12c has been made available I was of course keen to see how to apply it. For a first test I opted to use my 3 node RAC cluster which is running on Oracle Linux 6.4 with UEK2. This post is not terribly well-polished, it’s more of a log of what I did…
The cluster makes use of some of the new 12c RAC features such as Flex ASM but it is not a Flex Cluster:
[oracle@rac12node3 ~]$ srvctl config asm ASM home: /u01/app/184.108.40.206/grid Password file: +OCR/orapwASM ASM listener: LISTENER ASM instance count: 2 Cluster ASM listener: ASMNET1LSNR_ASM [oracle@rac12node3 ~]$
My database is a standard 3 node administrator managed build:
Recently I am involved in a project which requires a lot of data to be extracted from Oracle. The size of the data was so huge that the filesystems filled up. Compressing the output (using tar j (bzip2) or z (gzip)) is an obvious solution, but this can only be done after the files are created. This is why I proposed compressing the output without ever existing in uncompressed form.
This solution works with a so called ‘named pipe’, which is something for which I know for sure it can be done on Linux and unix. A named pipe has the ability to let two processes transfer data between each other. This solution will look familiar to “older” Oracle DBA’s: this was how exports where compressed from the “original” export utility (exp).
I’ve created a small script which calls sqlplus embedded in it, and executes sqlplus commands using a “here command”:
I just learned something new yesterday when demoing large page use on Linux during my AOT seminar.
I had 512 x 2MB hugepages configured in Linux ( 1024 MB ). So I set the USE_LARGE_PAGES = TRUE (it actually is the default anyway in 220.127.116.11+). This allows the use of large pages (it doesn’t force, the ONLY option would force the use of hugepages, otherwise the instance wouldn’t start up). Anyway, the previous behavior with hugepages was, that if Oracle was not able to allocate the entire SGA from the hugepages area, it would silently allocate the entire SGA from small pages. It was all or nothing. But to my surprise, when I set my SGA_MAX_SIZE bigger than the amount of allocated hugepages in my testing, the instance started up and the hugepages got allocated too!
When you are administering an Exadata or more Exadata’s, you probably have multiple databases running on different database or “computing” nodes. In order to understand what kind of IO you are doing, you can look inside the statistics of your database, and look in the data dictionary what that instance or instances (in case of RAC) have been doing. When using Exadata there is a near 100% chance you are using either normal redundancy or high redundancy, of which most people know the impact of the “write amplification” of both normal and high redundancy of ASM (the write statistics in the Oracle data dictionary do not reflect the additional writes needed to satisfy normal (#IO times 2) or high (#IO times 3) redundancy). This means there might be difference in IOs between what you measure or think for your database is doing, and actually is done at the storage level.
Exadata gets its performance by letting the storage (the exadata storage server) participate in query processing, which means part of the processing is done as close as possible to where the data is stored. The participation of the storage server in query processing means that a storage grid can massively parallel (depending on the amount of storage servers participating) process a smart scan request.
Following on from my recent batch of “what I’m doing at the moment” style posts, I just thought I would mention some of the infrastructure I’ve been installing and configuring recently…
We are still part way through a migration from Oracle Application Server to WebLogic 11g. There are many applications to migrate and test, fortunately not by me, but they fit into two main categories.
The purpose of this post is to show what the wait event ‘cell smart table scan’ means, based on reproducible investigation methods.
First of all, if you see the ‘cell smart table scan’ event: congratulations! This means you are using your exadata how it’s intended to be used, which means your full table scan is offloaded to the cells (storage layer), and potentially all kinds of optimisations are happening, like column filtering, predicate filtering, storage indexing, etc.
But what is exactly happening when you see the wait event ‘cell smart table scan’? Can we say anything based on this waits, like you can with other wait events?
This is a quick post about how you can get the debuginfo packages on your Oracle Linux system in the easiest way thinkable: via yum.
I guess most people reading this are familiar with Oracle Linux, and do know how to install it, and how to use the public yum server to install and update packages on Linux right from Oracle’s free internet repository. If you do not know, follow the link and learn.
As a sidestep from the purpose of this blog articel: during the ACE Director briefing prior to Oracle Openworld Wim Coekaerts announced that the public-yum repository is now hosted on Akamai instead of somewhere “unofficial” in the Oracle infra. This is really, really noticeable when using it now, previously I could not get beyond a speed of approximately 500K/s, now I can get speeds of 10M/s.
Following from yesterday’s post about Cloud Control 12cR3, Oracle Linux and VMware, I thought I would just mention something I put live yesterday evening.
We have a 3rd party Java-based application that runs on Tomcat 7 and Java 7 that until recently was running on RHEL5 on physical hardware. It runs against an Oracle database, but that is not housed on this server. This application is not that big, but it is *very* high profile as it is what we use to process our REF submissions. If you know anything about higher education in the UK, you’ll know that REF is a very big deal, especially as we are within a couple of months of the next submission.