Tom Kyte 關於 Oracle 11g 的最新問題答覆

Tom Kyte 關於 Oracle 11g 的最新問題答覆[@more@]三月號的 "Database trends and application" 雜誌。

Oracle 11g, in Beta, Makes the DB More Accessible
Tom Kyte provides the first, and exclusive, look at the 11g enhancements geared toward database developers.
Industry Leader Interview

DBTA: Oracle 11g beta was announced in October. What can people look forward to?
Kyte: I would like to start with PL/ SQL enhancements, particularly in the performance area. Today, everybody is building Web applica­tions. A lot of these are read- only or read- mostly applications. They run against repositories of relatively stat­ic or slowly- changing information. In 11g, we have the ability to cache the results of SQL queries that have been executed.

DBTA: Haven't databases always been able to cache information?
Kyte: They cache database blocks. 11g will look at queries, and if people are asking the same query over and over again, it can keep the answer separate so the next person who executes the query does not have to go through a million database blocks to get a one­row result.

DBTA: What if the underlying data changes?
Kyte: Since we are doing this in the database kernel itself, if the underlying data changes, we can validate the cache. This is transparent to the appli­cation. Typically, developers decide what they want to cache and read that into a middle- tier application for performance.

DBTA: And with 11g?
Kyte: We have taken that and put it into the database. This new cache that we have developed is like a just-in-time materialized view. The DBA doesn't have to create the materialized view. They say which objects are cache-able in the database and the database does the rest of the work. We can cache, not only the results of the SQL queries to make the functions faster, but also the results of the functions and proce­dures. We can define a function in 11g, and when developers code it, they can say “cache the results.” And if certain tables are modified, the result can be un-cached and can be recomputed and the new result cached. You can cache the results of queries, procedures and functions. And you have cache invali­dation at the database level. This could be analogous to setting a fast=true parameter for the first time for certain classes of applications. Everybody has been looking for the fast=true para­menter setting. They want a fix. It has to be fast and easy, and they can't change the application to make it hap­pen. This fits all of those requirements for certain classes of applications that mostly read data. It has general appli­cability in many applications.

DBTA: Oracle Application Express (APEX) is going to be a standard fea­ture in 11g. What is that all about?
Kyte: APEX is a database development tool. It is unique in that the developer installs nothing on the desktop. The entire APEX development and runtime engine is entirely in the database. In 11g, APEX will be installed by default. It will always be there. Once I have an APEX database up and running, from anywhere in the world, all I need is a standard Web browser to build applica­tions against my database.
DBTA: What else is new in APEX?
Kyte: In 11g, there is support for an embedded PL/SQL gateway directly in the database, which will support the standard and enterprise editions of the database. We can install an Oracle instance, connect to the database direct­ly from the Web browser and begin to develop applications. You don't need to install, maintain or configure a middle tier. They are in the database. You don't have to configure it that way, but it pro­vides the easiest out-of-the-box experi­ence. There are fewer moving pieces.

DBTA: What about application deployment?
Kyte: There is an application packager. I can write an application and, at a push of button, package it. If you build an application that you want to share with the world, you can package it up. It makes the deployment and redeploy­ment of applications pretty trivial. Deployment becomes “push one button here” and “one button there” and I have downloaded the application from one database to another

DBTA: 11g is supposed to make the lives of developers easier. What are you adding along those lines?
Kyte: At least once a week, I get a query on asktom.oracle.com about how to execute a 128KB SQL statement in PL/SQL. The simple answer is that you can't. Historically, PL/SQL had a limi­tation on character strings of 32KB. We are removing those little limits that held you back. You can now generate a PL/SQL dynamic string as a Character Large Object (CLOB) and execute it. It sounds like a small feature, but half the developers out there have run into this limitation and it stops them in their tracks. This is a totally different way to approach the problem DBTA: Sounds useful.
Kyte: We have also taken a lot of the worst practices people use in coding applications and put them into the com­piler. The compiler looks for these bad ideas and then warns developers that they are doing something questionable.

DBTA: Can you give me an example?
Kyte: One thing that has always both­ered me is how people handle excep­tions in PL/SQL. Exceptions are errors. A developer will code “when others, then null” - if something happens, ignore it. This is a major cause of bugs in applications. I can now walk into a shop that says that Oracle is behaving incorrectly and recompile the code with these warnings and find all the ques­tionable places in their application code. The PL/SQL compiler is more robust and can give more information. You can take somebody else's code, compile it and see the potential issues.
DBTA: Are people going to recompile a lot of code with this release?
Kyte: I hope so. This information is for acting on. You want to get the code to compile without any warnings. It will reduce the number of the bugs.

DBTA: What have you done in 11g in terms of .NET?
Kyte: We have a lot of support of Oracle specific function. We have a lot of high availability and failover capabilities. You have the same capabilities in .NET as in our native environment.

DBTA: And for Java?
Kyte: We will support the latest JDBC standards in the database. There is new standard data type support. There is support for an international character set. And we have put in a database change cache invalidation notification in the JDBC driver. The client applica­tion can know if what it has read from the database is stale. The client can be notified when changes occur.

DBTA: Are there other performance enhancements?
Kyte: Since 9i, we have had the ability to natively compile Java and PL/SQL applications. But it always required a third-party C compiler or Java compiler. In many production systems, however, the installation of a C compiler or a Java compiler is forbidden. And there was extra cost. With 11g, we have an operat­ing system compiler in the database. We are going straight from the source code to the operating system object code and storing it in the database. It no longer is a two-step process. The per­formance out-of-the-box is good.

DBTA: PHP has emerged as a popu­lar programming language. What have you done in that area?
Kyte: A problem we had with PHP was in the area of connection pooling. PHP did not support connection pooling for Oracle databases. We have developed a database-resident connection pool. It allows us to cache sessions on the serv­er side. As the application connects and disconnects, rather than having to create an entire session, we rejoin a pre-exist­ing session. It knocks out a lot of the work in establishing a connection.

DBTA: Overall, how would you sum­marize the changes in 11g?
Kyte: There has been a focus on making the database more accessible and easier to use for the developer community. There is a lot of community-based developer networking going on. Looking at PL/SQL, the improvements are in the areas of performance, usabil­ity and better functionality.



--------------------------------------------------------------------------------


Thomas Kyte Vice President, Core Technology Oracle Public Sector Division