Oracle Webcasts

Donald Burleson has compiled a rather large list of his webcasts. The topics range from deep technical Oracle topics to some good tricks for improving Google search results.

The webcasts are on different services and in different formats but they are all fairly short. Some of the topics are best suited to advanced audiences, but there’s plenty there for everyone.

Donald Burleson’s Oracle Webcasts

webcasts, oracle, oracle database, rdbms

ER Diagramming Tools

While investigating tools for generating ER Diagrams for the data warehouse I’m working on I came across this good article on databasejournal.com which compares three of the top CASE (computer aided software engineering) tools for Oracle.

In the article Steve Callan quickly highlights the differences between Microsoft Visio 2003, Oracle Designer and AllFusion ERwin Data Modeler.

What can we take home from this article? Well, Microsoft Visio is (relatively) cheap at $499 and has good reverse engineering abilities, but won’t write database creation code for you.

Oracle Designer is clumsy, but since it’s bundled with Internet Developer Suite you might already own it; otherwise you’re probably not likely to justify the $5,000 cost of entry.

ERwin really seems like the Cadillac solution for database modeling. The $3,995 price tag will put off most, but like they say in the auto industry, if you’re worried about gas mileage you’re not ready for a Cadillac.

Check out the full article for details. Also check out the Oracle section at DatabseJournal.com for some nice series on Oracle related topics.

oracle, database, rdbms, dbms, oracle database, database management, database design, dba, database administration, er diagramming, case, software engineering

Oracle Shared Pool Advisory

Over at the ITToolbox blogs there’s a great entry on the Oracle shared pool advisory in 9iR2. This type of article is great as it presents a tool, describes it, and walks you right through applying the knowledge.

Here’s their description of the advisory:

The shared pool advisory is an Oracle9i feature that keeps track of the library cache’s use of shared pool memory. While doing this it keeps statistics to determine the behavior of differently sized shared pools. Typically, the advisory will keep a bucket of statistics for shared pool sizes that range from 50% below your current setting to 200% of your current setting. It is then up to us as database administrators to use these statistics to determine what the size of the shared pool should be through the use of the view V$SHARED_POOL_ADVICE.

Check out the article for more information on how to enable and use the advisory.

oracle, oracle database, dba, dbms, oracle dbms, database tuning, database administration

Chronology of Oracle Blogs

OracleAndyC has compiled a short history of Oracle blogging.

It’s interesting to look at these in rough chronological order, and always nice to have a good list. Thanks Andy!

blogs, oracle, oracle database, database administration, dba, database

Compressing Extents in Oracle

While Oracle has been moving in the direction of locally managed extents in tablespaces several of us are still working with dictionary managed tablespaces. Here’s a good trick for adjusting table storage clauses in dictionary managed tablespaces.

Note: “compressing” extents is not a way to make data take up less space, but rather a way to take a fragmented (for lack of a better word) table and re-ogranize it into a more contiguous area of storage.

In the older dictionary managed method a storage clause in the table creation command controls how much space was initially allocated to that table (the initial extent) and how much would additionally be allocated if it filled the initial space (the next extent). If no storage clause was specified an often absurd default would be used.

This leaves us with two problems: First, we may have a very low value for the next extent. This can leave us creating extents of, for instance, 32KB even though each row may be 50KB.

Second, we may have tables which already contain a ridiculous number of extents and possibly chained rows. (Chained rows are a topic for another day.)

For my example I will use a table owned by system called session_audit.

To view the storage parameters on a table we can query the dba_tables view:

SQL > SELECT initial_extent, next_extent
FROM dba_tables
WHERE table_name='SESSION_AUDIT' AND owner='SYSTEM';

INITIAL_EXTENT NEXT_EXTENT
-------------- -----------
131072 65536

These numbers represent size in bytes, so dividing by 1024 we see that this table is configured to have an initial extent of 128KB and a next extent of 64KB.

We can also count the current number of extents whch make up this table with the following SQL command:

SQL> SELECT count(*) FROM dba_extents
WHERE segment_name='SESSION_AUDIT' AND
OWNER='SYSTEM';

COUNT(*)
--------
77

It may seem the right method is to change the initial and next values with an ALTER TABLE command like this:

SQL> ALTER TABLE system.session_audit
STORAGE (INITIAL 10M NEXT 5M);
ALTER TABLE SYSTEM.SESSION_AUDIT
*
ERROR at line 1:
ORA-02203: INITIAL storage options not allowed

If we dropped the change to the initial extent we could use this command to change the next extent. If we want to update the initial extent we will need to get sneaky. We could create a new table with the desired storage settings, move the data, then rename the new table to the old name, but this would cause the table to be temporarily unavailable and have the unfortunate side-effect of invalidating any of this tables dependencies. Alternately we could export and import the table but this would lead to the same problem.

Instead, using the ‘ALTER TABLE MOVE’ command, we can tell Oracle to move this table into a different tablespace while at the same time sneaking a new storage clause in.

SQL> ALTER TABLE system.session_audit
MOVE TABLESPACE system
STORAGE (INITIAL 10M NEXT 5M);

Table altered.

We now have our table in the new tablespace with the desired storage clause. This also creates an initial extent of the specified size instead of the smaller extents we had previously. If we want to move the table back to it’s original tablespace we can just issue the same command with the original tablespace.

NOTE: I was also able to tell Oracle to “move” the table to the same tablespace it was originally in. This had the same affect of changing the storage clause and compressing the extents without needing a foster tablespace.

We can now re-check the number of extents and storage clause for the table:

SQL> SELECT count(*) FROM dba_extents
WHERE segment_name='SESSION_AUDIT' AND
OWNER='SYSTEM';

COUNT(*)
--------
1

SQL > SELECT initial_extent, next_extent
FROM dba_tables
WHERE table_name='SESSION_AUDIT' AND owner='SYSTEM';

INITIAL_EXTENT NEXT_EXTENT
-------------- -----------
10485760 5242880

We see that the number of extents currently being used by the table has been reduced to 1 and our next extent will be 5MB in size.

oracle, database, database administrator, oracle database, dba, sql, database tuning