Feed aggregator

Strange behaviour of the CBO, part 2

Radoslav Rusinov - Thu, 2005-08-11 03:08
After playing around with setting of columns to allow NULL values or not (setting COL1 and COL3 to allow NULL values, test and put it again to their default condition) and precomputing statistics, the issue from previous post become more unclear.Now the structure of the table is the same like it was before, statistics are fresh but cost for the execution plan is always 175. It doesn't matter whatRadoslav Rusinovhttp://www.blogger.com/profile/18163031714036680150noreply@blogger.com0

Strange behaviour of the CBO, part 1

Radoslav Rusinov - Wed, 2005-08-10 11:36
The following interesting issue does not have clear explanation till now.I have query that is using the following predicates. ... AND COL1 LIKE '%%' AND COL2 LIKE '%%' AND COL3 LIKE '%%' AND COL4 LIKE '%%' ...May be I should explain from where is coming this strange query.If you are developping some application and you Radoslav Rusinovhttp://www.blogger.com/profile/18163031714036680150noreply@blogger.com2

How to see the MOD_PLSQL passwords in clear text

Radoslav Rusinov - Wed, 2005-08-10 09:37
If you have some web-based PL/SQL application then you can be interested in the following information.May be many DBAs who have been involved in the database security have asked themselves: "How to be sure that my DAD files hides well the application schema passwords?"Well, Oracle doesn't have very good solution for this problem.Lets take a look at one DAD file used from an Oracle Application Radoslav Rusinovhttp://www.blogger.com/profile/18163031714036680150noreply@blogger.com0

Forcing Oracle to use LOGGING mode

Radoslav Rusinov - Wed, 2005-08-10 08:43
I've just read an interesting newsletter about that how we can force the database (or some tablespace) to use the LOGGING mode for all operations. For example, lets imagine that we don't want someone improperly to start some operation in NOLOGGING mode that will lead the database to impossibility of performing of full database recovery after media failure. This could be important issue if a Radoslav Rusinovhttp://www.blogger.com/profile/18163031714036680150noreply@blogger.com0

Laws of Economics

Denis Goddard - Sun, 2005-07-31 14:15
I was listening to (a podcast of) this show and it tickled some things I've been thinking about a lot lately.

First, the laws of Economics are as valid and as real any any law of physics.
I mean this quite literally. The most well-understood economic laws are
those in idealized situations: millions of people, all acting (too) perfectly reasonably.
This is no different than the fact that Newton's Laws only hold for moles of atoms, all acting like little marbles.

Another notion I've been noodling lately is that the flow of currency through the world's people is
extraordinarliy similar in concept to the assignment of resources by an operating system.
It's not the agent that controls what happens; but it does describe how it happens.
Economics is literally the Operating System for Planet Earth.

As such, it behooves one to learn a little about Economics.
So, My plugs:

There's some more of my rant at a post on the abovementioned show's forum.

OK, back to working on this ADE Enhancement :-)

Hotel California

Denis Goddard - Tue, 2005-07-26 14:08
I just gotta say, I am so happy to be living in New Hampshire!

Aside from no state income tax, and way more trees and greenspace that California had,
the Live Free or Die state is attracting nationwide attention for the "Lost Liberty Hotel".
There was a great segment on Hannity & Colmes the other day.
Check it out!

Okay, I gotta get back to programming now...

iExpenses... things I learnt this week

Jo Davis - Tue, 2005-07-26 00:34
On 11.5.10 you can...
- display any or all of the AFF segments
- elect a percentage or otherwise of expense reports to be audited for receipts by Payables staff
- credit card charges from hotels can be itemised automatically in the upload
- policies (whilst great functionality) are a bit of a pain when trying to demo
- we can finally dispute credit card transactions on credit cards instead of just on P-Cards
- the credit card audit screen is a pain - can I go back to using the payables screen please? :)

Have a great day!

Array-based advanced queuing in 10g

Adrian Billington - Fri, 2005-07-22 03:00
Oracle 10g enables us to enqueue and dequeue in bulk. July 2005

Pl/sql timer

Adrian Billington - Fri, 2005-07-22 03:00
A simple package to output the elapsed time between two points. Supports versions from 8i onwards. July 2005

Introduction to advanced queuing

Adrian Billington - Fri, 2005-07-22 03:00
A high-level tutorial on Oracle's Advanced Queuing. July 2005

The Post Acquisition World.....

Jo Davis - Wed, 2005-07-20 23:31
Read an interesting article in the Australian CIO which raises a few points on the brave new world (post PeopleSoft acquisition) of ERP. Interesting. It might just be that the next few years are the time for everyone to sit back and have a bit of a strategic think about the world of ERP and effective strategies for managing it....


Wijaya Kusumo - Wed, 2005-07-20 03:51
Google map now has a branch in the moon! Google Moon, as it called, is unfortunately lacking the powerful locality search for now. Not until July 20th, 2069..... sigh!

Should we use Transparent Data Encryption?

Wijaya Kusumo - Tue, 2005-07-19 02:08
If your data requires the highest level of privacy and security, by all means, use it. However if it falls somewhere in the mid to low range, then you may want to carefully consider your options.   Transparent Data Encryption (TDE) is a new feature of Oracle 10gR2 database that provides transparent encryption and decryption of table columns. Transparent means there is no code change required,

TLA Clarifications

Denis Goddard - Mon, 2005-07-18 09:08

It has been brought to my attention that I used (and will continue to use) the term "SCM" in my blog, and that this TLA has two meanings: Oracle Supply Chain Management, and Oracle Software Configuration Manager.
Please take note: I always mean the latter, and never the former. I'm deeply involved with Oracle's Software Configuration Management system, and have nothing at all to do with Supply Chain stuff. By the way, no, I had nothing to do with choosing this name, though I confess I think it's pretty cool to work on a product whose acronym is pronouncable as "Scum".

Another common acronym in my namespace: ADE. That stands for Advanced Development Environment. No, I didn't choose this name either. ADE is the name given to the Perl-based front-end of the SCM system. My plan is to get rid of it, by which I mean, to move all (or the vast majority of) the code from the client side into middleware and server-side logic. SCM10 will take us about 75% of the way to that goal. ADE was originally envisioned by Dr. Alan Demers as a way to minimize the impact of the fact that ClearCase (which we used at the time) kept crashing. I took Al's ball and ran with it -- ADE became the technology to migrate all of our SCM data out of ClearCase and into an Oracle database. Which brings us to...

ODE, in the context of SCM and ADE, stands for "Oracle Development Environment". I would really like to get rid of "SCM" and instead use "ODE", but for some reason or other the people who make these decisions aren't with me on that one :-)
Anyway, "ODE" has come to mean, the specific database instance that holds the SCM data for Server Technologies.

Well, There's a bit of Oracle TLA trivia for ya. If you want to hear way more about all the above at length at any time, buy me a few beers and I'll be happy to yammer at length.

Google map is now in Japan

Wijaya Kusumo - Fri, 2005-07-15 03:50
Google map now covers the land of samurai. The map's look and feel is quite different from other region (US,UK, Canada). It has more info and show the building lay out as well. Too bad the satellite view is not as good as US.http://maps.google.co.jp


Denis Goddard - Tue, 2005-07-12 10:55
Make it so!

So... here's a blog. My own blog.
Oye am thonthorstrok, thing mud.

I thought for a bit about having a separate Blog for work (Oracle) and personal stuff.
But really, I know I'll be lucky to keep up with just one blog.

To adulterate Benjamin Franklin: "A blog... if you can keep it"

Plenty more to say, but I need to focus on work now: getting ADE 3.2 Beta tidied up,
and planning out how to transition development of 3.2 to Bangalore, while getting the
US Dev Team trained up and ready to work on SCM10 (the Next Big Thing!)

Personalisation makes it to the forms-based apps

Jo Davis - Sun, 2005-06-26 06:35
Okay, so anyone who's been subjected to my ravings at OAUG conferences knows what a big fan I am of not customising..... hold onto your hats because the personalisation functionality from the self-service web apps has a new cousin in 11.5.10 - personalisation of the forms based screens! Move over folder tools and custom.pll, now we're really cooking with gas..... Ramakrishna Goud has put together a nice white paper on it. It's definately not in 11.5.9 - maybe I can find a patch on metalink to back-port it? They're just making 11.5.10 more and more worth the hassle every day aren't they... I think it's a plot :)

Took an insane quiz and apparently I'm a caramel - who knew?

Jo Davis - Mon, 2005-06-13 03:35
This blog just wouldn't be complete unless I took some insane quiz and bored you all with the results....

You're a Caramel!! You are known for your
sweetness. You are comfortable with yourself,
and help others feel the same way about
themselves. You are generally friendly to
everyone, and believe in second chances.

Which kind of candy are you?

And the nutty part... that's actually quite true, and not such a bad thing I reckon, since I happen to be a consultant for a living ;)

Name 5 integration Points between the Oracle eBusiness Suite and the Desktop.... go!

Jo Davis - Sat, 2005-06-11 22:04
Here's my ten:
1) j-Initiator launch
2) workflow and mail client (as in notifications)
3) export to excel (as in (N) File > Export)
4) attachments - loading and accessing
5) web ADI - create a spreadsheet
6) upload a journal from a web ADI spreadsheet
7) export to printer (as in (N) File > Print)
8) define and upload rates in the new currency rates manager (aka another clown suit for Web ADI)
9) every single fun thing in Client-Server ADI
10) ditto for Discoverer ;)

Don't you love sociability testing with multiple desktop SOEs?

Application metadata and annotations from beside the bandwagon

Mike Keith - Tue, 2005-06-07 18:52

For those who know me I'm sure the title was enough. You already know what I am going to run on about in this blog entry and are probably just reading on to find out exactly how vigorously I am going to spew.

The simplest definition of metadata that I can think of is data that describes other data. Like regular data it must be persisted somewhere in order for it to endure beyond the program that created it. It can appear in many forms; in some cases it can be found stored in the database, in others it may be in the file system. Back in the Smalltalk days metadata about classes was stored as metaclasses and persisted as part of the runtime image itself. To summarize, it is the function, not the form, of the data that makes it metadata.

Okay, let's move on to annotations and how JSR 175 is supposed to change the way that we program in Java.

So what is the problem that annotations solve? Well, since Java code is really just another type of data it turns out that we often need data to describe it as well. Traditionally we have used various formats for storing and associating the metadata with the Java code, and obviously the one most commonly used within the last few years has been XML files. In XML the metadata is typically structured inside of multiple levels of XML elements that include the names of the Java artifacts, and this is all in order to link the two together. The problem is that the metadata and the Java code that it describes are separated from each other. This introduces all sorts of problems, from persistent storage of the metadata to retrieving it and associating it at processing time, or runtime, or whatever time the two need to be linked. Annotations introduced a way to couple them within the language format so that they are stored in the same place, loaded at the same time and accessible whenever the Java program is. We no longer need to go out into an entirely different language, grammar and syntax and embed the metadata within a myriad of XML elements that exist solely to tell us which Java artifacts the metadata applies to.

So if annotations are so great then why am I discontented? Because I can't use them. In particular, I can't use them for anything other than their simplest and most obvious usage. I want to use them for metadata that applies to a group of classes. I want the same ease of use at the application level that I get at the class level.

It really scrapes my elbows that there was such a lame attempt at supporting annotation metadata at the level that applies to multiple classes. The so-called package-info.java mechanism is too crippled and clumsy to be usable, and the result is that it has left such a bad taste in everybody's mouth that they want to spit whenever they get reminded of anything related to annotations above the level of classes. It doesn't help that Java does not have any notion of a module, or enclosing configuration-friendly wrapper around bunches of Java code. Combine these together and it becomes hard to dispute that Java is doing a pretty lousy job accommodating application-level metadata.

The fact that Java has failed to provide a decent mechanism to support application-level annotations by no means implies that application-level annotations are a bad idea. Remember that annotations are just a way of specifying metadata. In fact, they are a preferred format than XML if the metadata is already coupled to Java code, and does not need to be portable to other platforms outside of Java, which is almost all of the time. There are lots of other reasons why people might want to use annotations instead of XML, ranging from development processes that are not geared for configuration management and version controlling of XML files to having different editing environments that are required for managing XML and Java. Some people have had such bad XML experiences that they shun it whenever possible. Regardless of the reasons, annotations are a much neater, more consistent way of adding metadata to Java programs that integrates perfectly with programming in Java. The code completion of annotations inside the Java editor, the brevity of their format and the compile-time checking that comes for free already combine to make it a superior environment for metadata programming than XML.

There are two main complaints that I have heard from critics of application-level annotation metadata. The first is that annotations should not be used for a group of application-level classes because there is no reasonable Java artifact on which to tack the annotations. This is true, of course, but quite beside the point. While the metadata ideally should be on a Java module no such module exists right now (although I believe it is being kicked off as a JSR even now). There is absolutely nothing stopping us from using whatever artifact we choose to store the metadata on as long as we have designated it as such. A class of our choosing will do the job for now... a no worse suggestion than using one for a global Persistence bootstrap point. It's no more or less a correct use for a class. The idealist may scoff at this saying that it is not the *correct* use of annotations, but my response is that just because the perfect target for the annotations does not exist does not mean that we can't adapt to the shortfall that exists in Java. The same idealist probably also criticizes the use of an interface to group a number of shared constants together, but that does not mean that it is not useful as a constant pool. When we don't see exactly what we need in Java most people won't say, "Since Java does not have what I need then I should probably not do it at all." We have a need or a design in mind and we use whatever tools are at our disposal to accomplish it. In this case we want to be able to use annotations to specify application-level metadata. We can make it work quite easily, so why shouldn't we?

The second argument that I have heard is that application metadata is not coupled to the code and therefore should not be specified as annotations on code. This is then always followed by the comment that you would have to recompile the annotated class in order to change the metadata. In the first case it is incorrect, while in the second it is both erroneous and inconsistent.

Application metadata can be divided up into two types of metadata, that which is tightly coupled to the code, and that which is loosely coupled to the code. As an example of tightly coupled metadata consider the EJB Persistence API where currently the @Entity annotation must have the access member set to FIELD if mappings are to be defined on the member fields instead of on properties. Setting this for all of the classes in the application will ease development considerably for the many people that like to use direct field access instead of the getter/setter property accessors, but changing the application level default definitely affects each and every class that did not explicitly specify the access mode. Ditto for the named queries which are defined for the entire application and referenced within classes that call em.createNamedQuery("MyFavoriteQueryName").

There can also be metadata that is only loosely coupled to the code. An example of this kind of metadata would be something like the run-as security role for a method. This could potentially change without changing the code, meaning it is not tightly coupled to the code, although some code in the method might well access resources that assume a particular user and would fail if the wrong user tried to execute it.

If you have not spotted the inconsistency yet it is that this same loosely-coupled metadata that is not supposed to be in an application-level annotation because it will require recompilation happens to already be present as a @RunAs annotation on the bean class, even though it will require a recompile of the class. The reason? First, because it is almost always the same person that does the metadata as the one that does the development, and putting it on the bean class is just easier than having to go into a separate XML file to do it. Second, (this is the erroneous part for those following along at home) in practice it makes no difference that we have to recompile the annotated class before redeploying the application. The reality of it is that there is no practical difference between clicking an IDE button to recompile and insert a class into an archive, and clicking a button to insert an XML file into an archive. Both require updating the application archive and redeploying the application. There is no justification for saying that this is okay for class metadata, but not for application metadata, though. They are equivalent in both senses.

Now if you took away from this the fact that I think Java annotations are the greatest thing since the Turing machine then I have obviously failed to get my point across. Java annotations still have problems -- lots of 'em. While they do provide a basic level of support for specifying metadata they do not support many of the things that they really ought to have. That s not the object of this rant, however, and I have already griped about those things here.

It's not chic these days to say that application-level annotations are good, and I may be added to a blacklist somewhere now that I have made my opinions public, but to me annotations are a means of specifying metadata by storing the metadata on Java artifacts. Essentially they are post-it notes for Java. Why do people insist that every post-it note I put on the fridge has to be about the freakin' fridge?


Subscribe to Oracle FAQ aggregator