We had a request on AskTOM a few days ago asking for an implementation of the XIRR function in PL/SQL.
I didn’t really know much about what that function was, or what it did, but a quick web search yielded plenty of examples in Excel, where it is a pre-delivered function, as described here:
“Returns the internal rate of return for a schedule of cash flows that is not necessarily periodic.”
The development teams often see the database as a ‘persistence layer’ only. And sometimes it is mentioned that the database is always the cause of the problems, especially when implementing continuous integration and trying to be agile. Then cames the idea to have this ‘persistence layer’ in an isolated environment, such as a docker container, with the database for each developer. However, this overlooks the real cause of the problems, which is not the persistence function of the database, but the fact that it is shared. And when you share something, in a multi-user environment, you reach another level of complexity. And if you are not prepared for that, you perceive it as a problem.
This philosophical blog post contains some cool words which, in my opinion, must be carefully considered when dealing database: agile, persistence, stateless, docker, microservices, stateless, NoSQL, containers, lake, cloud,…
The deletion policy on a dataguard configuration should be:
for the site where you don’t backup. It can be the standby or the primary.
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
and:
for the site where you do the backups. It can be the primary or the standby.
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DISK;
I’ve always configured it in this way, but I recently discovered that the order of the subclause matters. Do not CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK APPLIED ON ALL STANDBY; because no archivelogs will be reclaimable, and your recovery area will be full. This is probably a bug. I’ll update this post when I have more information about this.
Recently I was triggered about the ‘automatic big table caching’ feature introduced in Oracle version 12.1.0.2 with Roger Macnicol’s blogpost about Oracle database IO and caching or not caching (https://blogs.oracle.com/smartscan-deep-dive/when-bloggers-get-it-wrong-part-1 https://blogs.oracle.com/smartscan-deep-dive/when-bloggers-get-it-wrong-part-2). If you want to read something about the feature in general, search for the feature name, you’ll find several blogposts about it.
The new release of Oracle VM VirtualBox (aka VirtualBox) is there with a new functionality to export a VM to the Oracle Cloud Compute (aka Oracle Cloud Infrastructure). That can be interesting to prepare a VM on my laptop and move it to the Cloud to get it accessible from everywhere. Here’s my first try. In my opinion, it’s idea but probably need further evolution.
Here is what is new: in addition to .ova you can export to an Oracle Public Cloud image:
This blog post is part of a series that discusses how to get optimal performance from PeopleSoft nVision reporting as used in General Ledger.
In this post, I examine the effect of different settings for the tree performance options on how the SQL is generated. It is common, to see different performance options in use on different trees in the same SQL query. It is important to be able to look at a piece of SQL generated by nVision and to be able to work out which performance options have been set on which trees.
Many bloggers have already discussed that Oracle can truncate the text of a “create table as select” statement to 20 characters depending on your version and patch level. This can be a problem in case a CTAS statement is a resource hog, yet you don’t see the SQL text that is needed for troubleshooting. A quick search on My Oracle Support reveals this can happen on 11.2.0.4, 12.1.0.1 and 12.1.0.2 systems unless patched of course. This has been bugging me for quite some time now, and merits a blog post.
Oracle has provided a number of patches over time to fix this undesirable short-cutting of the SQL text. I wanted to reproduce the issue on 12.1 to demonstrate the effect. To my shame I have to admit that since 12.2 has come out I have somewhat neglected my 12.1 lab system. It was quite a bit out of date, which was useful for this blog post as it will turn out.
Many of you know what a “Smart-Arse” is. For those who do not…
A “Smart-arse” a person who is irritating because they behave as if they know everything or try to catch you out by misleading you.
A smart person will look at your problem and say something like “have you tried checking the array size?” and, 8 times out of 10, their input will help you solve your problem. It may not be THE answer but it makes you think about root causes.
A Smart-arse will say something more like “well, I would never have your problem as I would not have joined a company full of Java Nerds!!!”. Yeah, maybe that would have avoided my specific problem #1, but it is of no practical worth right now. .
OK, Now that I’ve started the post with a nice click-bait heading, let’s get down to the business of being wrong.
I did a lot of conference presentations last year, and the great thing about that for me was that I got to meet a lot of new people in the Oracle community in the Developer and DBA space. One of the questions that came up over and over again was about putting one’s knowledge “out there” in the community and how to deal with the repercussions of that. In particular, “What if you publish something that is proven wrong?”
Here’s the thing about being wrong …. there’s two likely outcomes:
Recent comments
1 year 45 weeks ago
2 years 5 weeks ago
2 years 9 weeks ago
2 years 10 weeks ago
2 years 15 weeks ago
2 years 36 weeks ago
3 years 4 weeks ago
3 years 34 weeks ago
4 years 18 weeks ago
4 years 18 weeks ago