Oracle 12c introduced a new capability to move a partition online, without any interruptions to DML happening at the same time. But, there’s a catch. So far we’ve been able to use basic table compression without having to worry about any extra licensing – it was just a plain EE feature.
If you are planning to use the online partition move functionality, carefully check if you’re not using basic compression anywhere. For example:
create tablespace data datafile '+DATA' size 1g
I’ve often found that while I’m investigating one Oracle feature I get waylaid by noticing anomalies in other parts of the code. I was caught by one of these events a little while ago while experimenting with the new (18.104.22.168) Inmemory Columnar Store. After reading a posting by Martin Bach I asked the question:
If you don't already know, then you should almost always be using bind variables in all SQL statements used in any applications you write that run against Oracle. Bind variables are place holders within your SQL statements that get replaced by real data values at run time when the SQL statement is executed i.e. at run time the real data value is "bound" to the corresponding place holder variable in the SQL statement. So rather than using unique SQL statements with explicit data values embedded in them:
I’m speaking at the Perth leg on the OTN APAC tour on December 2nd, eCentral TAFE, East Perth
This is a great event with local and international speakers all giving their time and knowledge for free to help you with your Oracle technology.
If you’re in Perth, then come along for some great education. Even if you cannot attend the conference, if you are in the area, come along and say Hi. Part of my job focus is helping developers succeed with Oracle, so we might be able to organise something in the future in terms of (free) education for your development teams.
I've setup an ASM Instance on my training system, Oracle 22.214.171.124 running under Oracle 6 Linux.
A question refering to Failure groups:
Setup as follows:
Diskgroup holds 2 Failgroups, 4 Disk each, normal redundancy.
Now disk2 in failgroup 2 becomes unavailable.
I think ASM will react like this:
a) Wait until Diskrepairtime passes
b) drop disk2 from failgroup2
c) rebalance failgroup2. after the rebalance of fg2 is finished all extens formely on disk2 have been copied to disks 1,3 and 4 of failgroup2
Just a quick note for anyone upgrading Apex on their systems.
The installation (into a non-multitenant 126.96.36.199 instance) went through with no problems, but tracing the installation suggests it will flush the shared pool 6 times during installation/upgrade.
That might have some impact on other applications/sessions running on that database, so best to find a quiet time to do it.
Recently on a heavily used and freshly upgraded 188.8.131.52 ware-house type database, we started seeing lots of ORA-10173 dumped into the alert log. The information out there on this error is somewhat sparse, and it is often linked to Tuning Advisor functionality. Since we’re not running that advisor on this database, a little digging was in order.