I’ve been told that using NOT EXISTS in (Oracle) SQL is a bad idea, and that a way to overcome this problem is to collect the non-matching rows with an OUTER JOIN. So I decided to check if it is true.
While perusing the Oracle 11g Data Pump documents recently, I noticed a new parameter that was introduced in Oracle 10g, but I had missed it there. The parameter is TABLE_EXISTS_ACTION, and it applies only to the Data Pump Import. Basically, this feature allows you to decide how to handle importing data if a table already exists. Let’s create a simple test case to demonstrate.
I gave this talk covering the different types of memory, how to monitor memory, and how to optimally use it with Oracle at the UKOUG, I have since received requests to post the slides online. Instead of just posting the PowerPoint I took some time to give the presentation again (internally here at Pythian) and this time we recorded the session and are posting it in a variety of formats. This is a bit of a departure from the typical Pythian Goodies, in that it is scripted, and there is a lot of content here in the whitepaper.
Oracle Grid Control documentation warns against leaving the emkey in the Grid Control repository, if it is not removed after it has been copied it is easy to decrypt data, like passwords. Oracle Management Service 10.2 uses several ways to protect these sensitive data, including Virtual Private Database and Password Encryption. To overcome the first one, you have to connect to the database as the SYS user, for the second one, you have to know the encrypted password form, the key, and the associated algorithm. Obviously, the key used to cipher the password is the emkey. So the next question is, “Where are stored the ciphered passwords?”.
I’m a Linux fan, and when it comes to specific problems, I’m afraid not all operating systems are equally armed. Enabling a specific user to listen on a port below 1024 is one of these problems that was solved for years with various approaches. So you may think, obviously you can access the GridControl 10.2 agent on Linux with HTTPS only, on port 443! And obviously you can — but…
This will be the final post in my series on Result Caches. In my previous article, I had already got almost everything. Almost — four CPUs (cores) were still not enough to saturate the single latch. As you’ve probably already guessed, today we are going with an eight-way test. Please note that today’s numbers are different since I’m using an entirely different hardware platform. While the four-way tests were done on 2.4GHz Core 2 Quad box, today’s eight-way tests were done using four dual core Itanium 2 CPUs running at 1.1GHz. Let’s take a look at the results…
I’m going to present couple sessions at the Australian Oracle User Group Conference in Melbourne next week. It’s the first time I’m presenting Down Under and I’m looking forward to it, although I’m still not sure if I should start from the last slide and proceed backward. It seems like I will never finish this blog post so I will be brief now and simply hint you what you can find in the next one. Nuno Souto, aka Noons, was very kind to invite me to his place for a dinner, and I can tell you it was fantastic evening. But this is a topic for the next photo-blog. Stay tuned!
Just a short blog entry about a funny error message I’ve got while trying to activate a physical standby database
I have recently stumbled upon V$SESSION_CONNECT_INFO view and discovered that it provides interesting information about client-side software and settings. Using this view in Oracle 11g you can simplify collecting some statistics about database clients. Here is what can be extracted.
If this post seems a bit like an “advertorial”, please believe me — it’s not. Well, at least it’s not an advertisement for Pythian in any way. What it is, however, is a post about a longstanding business partner of Pythian’s who run a very useful service I think more of you should know about. Rest assured there is nothing “in it” for me or for Pythian for writing this.