If you haven't had a chance to work with it, consider visiting

http://dlc.sun.com/virtualbox/vboxdownload.html

It runs on windows, linux, mac os/x and solaris.

I downloaded a pre-installed VM with a database, development tools, and an application server pre-installed.  Though I had the minimum required config (~2 GHz processor, 2 GB RAM), I was surprised that it ran as well as it did.

Though the initial setup is quite quick, the downloads of actual VMs to use in VirtualBox can take a while, but compared to the aggravation of pulling together Oracle 11gR2, SQL Developer, Apex, and a Weblogic server on your own, it's a more than fair trade.

If you've been putting off exploring Hands-On Database Technology on a home PC or a spare machine at work (http://www.oracle.com/technetwork/database/enterprise-edition/databaseappdev-vm-161299.html), then this could be a good way to jump in — with a virtual machine.

Anyone who's used SQL Developer may have noticed the search engines tucked away in the upper right corner of the screen.  With a nod to Firefox, the people who created SQL Developer made it easy to look up an error message on Google, consider going to Oracle Technology Network (OTN) forums with your SQL Developer issue, or checking the AskTom or Oracle documentation sites.  

While the sites provide valuable information, often they get into esoteric areas or long blogs.  PSOUG succinctly exposes the concepts that a developer needs right away with examples of usage and scripts that illuminate topics such as CREATE MATERIALIZED VIEW.

It's exceedingly easy to try out.  Add PSOUG to your search domains by placing an image file and a source file in the sqldeveloper/sqldeveloper/searchengines path of your installation.

First file: psoug.src

<search
   name="PSOUG"
   description="PSOUG Search"
   method="POST"
   action="http://psoug.org/search.htm"
   searchForm="http://psoug.org/search.htm"
   queryEncoding="utf-8"
   queryCharset="utf-8"
>

<input name="qwords" user>
<input name="querytype" value="allwords">
<input name="catid" value="0">
<input name="searchtype" value="basic">
<input name="submit" value="GO">

<interpret
    browserResultType="result"
    charset = "UTF-8"
    resultListStart="<!–a–>"
    resultListEnd="<!–z–>"
    resultItemStart="<!–m–>"
    resultItemEnd="<!–n–>"
>
</search>

Second file: psoug.gif

I downloaded the PSOUG title.gif and scaled it down by a factor of about 4.  Use whatever tool makes sense to manipulate your image such as GIMP (multi-platform)  or Microsoft's Image editor, or whatever works on the Mac OS/X into an icon-sized image.  Jpeg, png, gif are all acceptable formats.

Your files will be discovered automatically the next time you start SQL Developer.

Dear DBA, as I am running loadtests with product XYZ in preparation
for uploading of many thousands of XML documents , I find that there is something
that's bogging down your database. I thought your equipment
should easily outpace the old Compaqs that we have running Windows, and that
Oracle should do better than our PostgreSQL-based setup. Yet
I find the numbers show the opposite:

733 Documents in 2325.713 s for an average of 3.173 s
at ~11% CPU load

944 Documents in 1960.4 s for an average of 2.077 s
at ~15% CPU load

It takes 50% longer on the Oracle setup. Since the
application server load is negligible at the same time, it
goes to show that we are waiting for the database.

I wonder why.

Hmmm, I thinking that this developer is not acquainted with the Oracle database technology choices available to him. He continues on.

Since I can not observe the Oracle database server's IO and
CPU activity directly, I have looked at the Oracle ADVISOR
report [Query 2: ADVISOR REPORT below]. I am showing
the most important part from report on task_id 4313
and task_name ADDM:6344221675_1_1349:
|
| FINDING 1: 60% impact (489 seconds)
| ———————————–
| Waits on event "log file sync" while performing COMMIT and ROLLBACK
| operations
| were consuming significant database time.

Is there anything you could do about this? For example, could
you move the redo logs onto a different disk device? Or is this
database or hardware very busy processing other transactions?

The loading of data might take at least 50% longer than expected
(and possibly more, because we'll hit the database with 4-8
processes in parallel). Your help will be much appreciated.

regards,
Prince

Dear Prince-
We've noticed many (hundreds of thousands) insert statements being executed through jdbc-client and wondered what your commit strategy was.

Sometimes java programs have auto commit turned on (every DML statement is committed one-at-a-time). If that's the case, then it is causing a lot of round-trips through the network to confirm a committed row in the database.

Other times, a bulk load will attempt to load thousands of rows at a time before committing. That can cause the growth of a large amount of undo segments that slows throughput as well. If that's the case then the commit interval needs to be changed.

If you are using jdbc's addBatch and executeBatch methods for processing multiple SQL statements, then you can make adjustments in how many rows in the batch that you need to commit.

Alternatively, you could make modifications to commit pending transactions after a given number of iterations in your code. If possible, try starting at 500 and varying it either higher or lower to meet your throughput goals.

One thing you should know about the test database that we're hosting is that we are not collecting and archiving redo logs.

We circulate through the logs very frequently. We have enlarged the redo log size to 200 MB (up from 55 MB), but we need to reduce the amount of redo being written. To that end, we recommend that the
insert SQL statements for the following tables be rewritten to use the "Append" hint since it appears that you are performing bulk load inserts on them.

If you want, we can even put the target tables into "nologging" mode during this phase where you need to load a lot of data. That would ensure that you could put hundreds of thousands of rows in the database in a very brief period of time.

1) Do you plan to

a) parse the XML docs and store them into multiple relational tables   ?

If so, what languages or techniques do you intend to use to accomplish this?

b) store an XML doc in a single XMLType column in the Oracle database?

Do you need to index the data to perform XML or "free text" searches?

If so, what XPATH indexing do you intend to perform?

c) Register XSD as an XML Schema and have Oracle validate incoming XML documents such that
data is automatically shredded into object-relational tables based upon the different
types and attributes?

If you choose (c), how will you reload and revalidate data against the new XSD should
new data elements become available in the XSD?

2) How important is it to preserve the exact XML document ingested in Oracle?

About Character Large Objects (CLOBs)

Yes, you can store CLOBs in line with a database row up to 4,000 characters, else it's written to a separate LOB segment.

Oracle automatically creates LOB indexes whether you want them or not, so you might want to review the non-XML CLOBS in your design and determine whether they would be well under the 4,000 characters and thus fit into a VARCHAR2 data column.