《java JDBC 外文翻译 外文文献 英文文献.doc》由会员分享，可在线阅读，更多相关《java JDBC 外文翻译 外文文献 英文文献.doc（21页珍藏版）》请在三一文库上搜索。
1、原文一：Java Programming with Oracle JDBC：PerformancePerformance is usually considered an issue at the end of a development cycle when it should really be considered from the start.Often, a task called performance tuning is done after the coding is complete, and the end user of a program complains about
2、 how long it takes the program to complete a particular task.The net result of waiting until the end of the development cycle to consider performance includes the expense of the additional time required to recode a program to improve its performance.Its my opinion that performance is something that
3、is best considered at the start of a project.When it comes to performance issues concerning JDBC programming there are two major factors to consider. The first is the performance of the database structure and the SQL statements used against it. The second is the relative efficiency of the different
4、ways you can use the JDBC interfaces to manipulate a database.In terms of the databases efficiency, you can use the EXPLAIN PLAN facility to explain how the databases optimizer plans to execute your SQL statements. Armed with this knowledge, you may determine that additional indexes are needed, or t
5、hat you require an alternative means of selecting the data you desire.On the other hand, when it comes to using JDBC, you need to know ahead of time the relative strengths and weaknesses of using auto-commit, SQL92 syntax, and a Statement versus a PreparedStatement versus a CallableStatement object.
6、 In this chapter, well examine the relative performance of various JDBC objects using example programs that report the amount of time it takes to accomplish a given task. Well first look at auto-commit. Next, well look at the impact of the SQL92 syntax parser. Then well start a series of comparisons
7、 of the Statement object versus the PreparedStatement object versus the CallableStatement object. At the same time well also examine the performance of the OCI versus the Thin driver in each situation to see if, as Oracles claims, there is a significant enough performance gain with the OCI driver th
8、at you should use it instead of the Thin driver. For the most part, our discussions will be based on timing data for 1,000 inserts into the test performance table TESTXXXPERF. There are separate programs for performing these 1,000 inserts using the OCI driver and the Thin driver. The performance tes
9、t programs themselves are very simple and are available online with the rest of the examples in this book. However, for brevity, Ill not show the code for the examples in this chapter. Ill only talk about them. Although the actual timing values change from system to system, their relative values, or
10、 ratios from one system to another, remain consistent. The timings used in this chapter were gathered using Windows 2000. Using objective data from these programs allows us to come to factual conclusions on which factors improve performance, rather than relying on hearsay.Im sure youll be surprised
11、at the reality of performance for these objects, and I hope youll use this knowledge to your advantage. Lets get started with a look at the testing framework used in this chapter.A Testing FrameworkFor the most part, the test programs in this chapter report the timings for inserting data into a tabl
12、e. I picked an INSERT statement because it eliminates the performance gain of the database block buffers that may skew timings for an UPDATE, DELETE, or SELECT .The test table used in the example programs in this chapter is a simple relational table. I wanted it to have a NUMBER, a small VARCHAR2, a
13、 large VARCHAR2, and a DATE column. Table TESTXXXPERF is defined as:create table TestXXXPerf (id number,code varchar2(30),descr varchar2(80),insert_user varchar2(30),insert_date date )tablespace users pctfree 20storage( initial 1 M next 1 M pctincrease 0 );alter table TestXXXPerfadd constraint TestX
14、XXPerf_Pkprimary key ( id )using indextablespace users pctfree 20storage( initial 1 M next 1 M pctincrease 0 );The initial extent size used for the table makes it unlikely that the database will need to take the time to allocate another extent during the execution of one of the test programs. Theref
15、ore, extent allocation will not impact the timings. Given this background, you should have a context to understand what is done in each section by each test program.Auto-CommitBy default, JDBCs auto-commit feature is on, which means that each SQL statement is committed as it is executed. If more tha
16、n one SQL statement is executed by your program, then a small performance increase can be achieved by turning off auto-commit. Lets take a look at some numbers. Table 19-1 shows the average time, in milliseconds, needed to insert 1,000 rows into the TESTXXXPERF table using a Statement object. The ti
17、mings represent the average from three runs of the program. Both drivers experience approximately a one-second loss as overhead for committing between each SQL statement. When you divide that one second by 1,000 inserts, you can see that turning off auto-commit saves approximately 0.001 seconds (1 m
18、illisecond) per SQL statement. While thats not interesting enough to write home about, it does demonstrate how auto-commit can impact performance.Table 19-1: Auto-commit timings (in milliseconds)Auto-commitOCIThinOn3,7123,675Off2,6132,594Clearly, its more important to turn off auto-commit for managi
19、ng multistep transactions than for gaining performance. But on a heavily loaded system where many users are committing transactions, the amount of time it takes to perform commits can become quite significant. So my recommendation is to turn off auto-commit and manage your transactions manually. The
20、 rest of the tests in this chapter are performed with auto-commit turned off. SQL92 Token ParsingLike auto-commit, SQL92 escape syntax token parsing is on by default. In case you dont recall, SQL92 token parsing allows you to embed SQL92 escape syntax in your SQL statements (see Oracle and SQL92 Esc
21、ape Syntax in Chapter 9). These standards-based snippets of syntax are parsed by a JDBC driver transforming the SQL statement into its native syntax for the target database. SQL92 escape syntax allows you to make your code more portable-but does this portability come with a cost in terms of performa
22、nce?Table 19-2 shows the number of milliseconds needed to insert 1,000 rows into the TESTXXXPERF table. Timings are shown with the SQL92 escape syntax parser on and off for both the OCI and Thin drivers. As before, these timings represent the result of three program runs averaged together. Table 19-
23、2: SQL92 token parser timings (in milliseconds)SQL92 parserOCIThinOn2,5672,514Off2,7442,550Notice from Table 19-2 that with the OCI driver we lose 177 milliseconds when escape syntax parsing is turned off, and we lose only 37 milliseconds when the parser is turned off with the Thin driver. These res
24、ults are the opposite of what you might intuitively expect. It appears that both drivers have been optimized for SQL92 parsing, so you should leave it on for best performance. Now that you know you never have to worry about turning the SQL92 parser off, lets move on to something that has some potent
25、ial for providing a substantial performance improvement.Statement Versus PreparedStatementTheres a popular belief that using a PreparedStatement object is faster than using a Statement object. After all, a prepared statement has to verify its metadata against the database only once, while a statemen
26、t has to do it every time. So how could it be any other way? Well, the truth of the matter is that it takes about 65 iterations of a prepared statement before its total time for execution catches up with a statement. When it comes to which SQL statement object performs better under typical use, a St
27、atement or a PreparedStatement, the truth is that the Statement object yields the best performance. When you consider how SQL statements are typically used in an application-1 or 2 here, maybe 10-20 (rarely more) per transaction-you realize that a Statement object will perform them in less time than
28、 a PreparedStatement object. In the next two sections, well look at this performance issue with respect to both the OCI driver and the Thin driver.The OCI DriverTable 19-3 shows the timings in milliseconds for 1 insert and 1,000 inserts in the TESTXXXPERF table. The inserts are done first using a St
29、atement object and then a PreparedStatement object. If you look at the results for 1,000 inserts, you may think that a prepared statement performs better. After all, at 1,000 inserts, the PreparedStatement object is almost twice as fast as the Statement object, but if you examine Figure 19-1, youll
30、see a different story.Table 19-3: OCI driver timings (in milliseconds)InsertsStatementPreparedStatement1101131,0002,8041,412Figure 19-1 is a graph of the timings needed to insert varying numbers of rows using both a Statement object and a PreparedStatement object. The number of inserts begins at 1 a
31、nd climbs in intervals of 10 up to a maximum of 150 inserts. For this graph and for those that follow, the lines themselves are polynomial trend lines with a factor of 2. I chose polynomial lines instead of straight trend lines so you can better see a change in the performance as the number of inser
32、ts increases. I chose a factor of 2 so the lines have only one curve in them. The important thing to notice about the graph is that its not until about 65 inserts that the PreparedStatement object outperforms the Statement object. 65 inserts! Clearly, the Statement object is more efficient under typ
33、ical use when using the OCI driver.Figure 19-1The Thin DriverIf you examine Table 19-4 (which shows the same timings as for Table 19-3, but for the Thin driver) and Figure 19-2 (which shows the data incrementally), youll see that the Thin driver follows the same behavior as the OCI driver. However,
34、since the Statement object starts out performing better than the PreparedStatement object, it takes about 125 inserts for the PreparedStatement to outperform Statement.Table 19-4: Thin driver timings (in milliseconds)InsertsStatementPreparedStatement1101131,0002,5831,739Figure 19-2When you consider
35、typical SQL statement usage, even with the Thin driver, youll get better performance if you execute your SQL statements using a Statement object instead of a PreparedStatement object. Given that, you may ask: why use a PreparedStatement at all? It turns out that there are some reasons why you might
36、use a PreparedStatement object to execute SQL statements. First, there are several types of operations that you simply cant perform without PreparedStatement object.For example,you must use a PreparedStatement object if you want to use large objects like BLOBs or CLOBs or if you wish to use object S
37、QL. Essentially, you trade some loss of performance for the added functionality ofusing these object technologies.A second reason to use a PreparedStatement is its support for batching.BatchingAs you saw in the previous section, PreparedStatement objects eventually become more efficient than their S
38、tatement counterparts after 65-125 executions of the same statement. If youre going to execute a given SQL statement a large number of times, it makes sense from a performance standpoint to use a PreparedStatement object. But if youre really going to do that many executions of a statement, or perhap
39、s more than 50, you should consider batching. Batching is more efficient because it sends multiple SQL statements to the server at one time. Although JDBC defines batching capability for Statement objects, Oracle supports batching only when Prepared-Statement objects are used. This makes some sense.
40、 A SQL statement in a PreparedStatement object is parsed once and can be reused many times. This naturally lends itself to batching. The OCI DriverTable 19-5 lists Statement and batched PreparedStatement timings, in milliseconds, for 1 insert and for 1,000 inserts. At the low end, one insert, you ta
41、ke a small performance hit for supporting batching. At the high end, 1,000 inserts, youve gained 75% throughput.Table 19-5: OCI driver timings (in milliseconds)InsertsStatementBatched1101171,0002,804691If you examine Figure 19-3, a trend line analysis of the Statement object versus the batched Prepa
42、redStatement object, youll see that this time, the batched Prepared-Statement object becomes more efficient than the Statement object at about 50 inserts. This is an improvement over the prepared statement without batching.Figure 19-3WARNING: Theres a catch here. The 8.1.6 OCI driver has a defect by
43、 which it does not support standard Java batching, so the numbers reported here were derived using Oracles proprietary batching.Now, lets take a look at batching in conjunction with the Thin driver.The Thin DriverThe Thin driver is even more efficient than the OCI driver when it comes to using batch
44、ed prepared statements. Table 19-6 shows the timings for the Thin driver using a Statement object versus a batched PreparedStatement object in milliseconds for the specified number of inserts.Table 19-6: Thin driver timings (in milliseconds)InsertsStatementBatched1101171,0002,583367The Thin driver t
45、akes the same performance hit on the low end, one insert, but gains a whopping 86% improvement on the high end. Yes, 1,000 inserts in less than a second! If you examine Figure 19-4, youll see that with the Thin driver, the use of a batched PreparedStatement object becomes more efficient than a State
46、ment object more quickly than with the OCI driver-at about 40 inserts.Figure 19-4If you intend to perform many iterations of the same SQL statement against a database, you should consider batching with a PreparedStatement object. Weve finished looking at improving the performance of inserts, updates
47、, and deletes. Now lets see what we can do to squeak out a little performance while selecting data.Predefined SELECT StatementsEvery time you execute a SELECT statement, the JDBC driver makes two round trips to the database. On the first round trip, it retrieves the metadata for the columns you are
48、selecting. On the second round trip, it retrieves the actual data you selected. With this in mind, you can improve the performance of a SELECT statement by 50% if you predefine the Selecstatement by using Oracles defineColumnType()method with an OracleStatement object (see Defining Columns in Chapter 9). When you predefine a SELECT statement, you provide the JDBC driver with the column metadata using the defineColumnType() method, obviating the need for the driver to make a round trip to the database for that information. Hence, for a singleton SELECT, you eliminate half the work when you pr