June 24, 2009

Temporary Tablespaces

What are Temporary Tablespaces: (reference: http://www.orafaq.com/node/2)

Temporary tablespaces are used to manage space for database sort operations and for storing global temporary tables. For example, if you join two large tables, and Oracle cannot do the sort in memory (see SORT_AREA_SIZE initialisation parameter), space will be allocated in a temporary tablespace for doing the sort operation. Other SQL operations that might require disk sorting are: CREATE INDEX, ANALYZE, Select DISTINCT, ORDER BY, GROUP BY, UNION, INTERSECT, MINUS, Sort-Merge joins, etc.

The DBA should assign a temporary tablespace to each user in the database to prevent them from allocating sort space in the SYSTEM tablespace. This can be done with one of the following commands:

SQL> CREATE USER scott DEFAULT TABLESPACE data TEMPORARY TABLESPACE temp;
SQL> ALTER USER scott TEMPORARY TABLESPACE temp;

Note that a temporary tablespace cannot contain permanent objects and therefore doesn't need to be backed up.

What are TEMPFILES?

Unlike normal data files, TEMPFILEs are not fully initialised (sparse). When you create a TEMPFILE, Oracle only writes to the header and last block of the file. This is why it is much quicker to create a TEMPFILE than to create a normal database file.

TEMPFILEs are not recorded in the database's control file. This implies that one can just recreate them whenever you restore the database, or after deleting them by accident. This opens interesting possibilities like having different TEMPFILE configurations between permanent and standby databases, or configure TEMPFILEs to be local instead of shared in a RAC environment.

One cannot remove datafiles from a tablespace until you drop the entire tablespace. However, one can remove a TEMPFILE from a database. Look at his example:

SQL> ALTER DATABASE TEMPFILE '/oradata/temp02.dbf' DROP INCLUDING DATAFILES;

If you remove all tempfiles from a temporary tablespace, you may encounter error: ORA-25153: Temporary Tablespace is Empty. Use the following statement to add a TEMPFILE to a temporary tablespace:

SQL> ALTER TABLESPACE temp ADD TEMPFILE '/oradata/temp03.dbf' SIZE 100M;

Except for adding a tempfile, as illustrated in the above example, you cannot use the ALTER TABLESPACE statement for a locally managed temporary tablespace (operations like rename, set to read only, recover, etc. will fail).

How does one create Temporary Tablespaces?

Oracle provides various ways of creating TEMPORARY tablespaces (mainly to provide backward compatibility). One should use the most recent method available:

- Prior to Oracle 7.3 - CREATE TABLESPACE temp DATAFILE ...;
- Oracle 7.3 & 8.0 - CREATE TABLESPACE temp DATAFILE ... TEMPORARY;
- Oracle 8i and above - CREATE TEMPORARY TABLESPACE temp TEMPFILE ...;

Oracle 8i and 9i example:

SQL> CREATE TEMPORARY TABLESPACE temp
TEMPFILE '/oradata/mytemp_01.tmp' SIZE 20M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;

For best performance, the UNIFORM SIZE must be a multiple of the SORT_AREA_SIZE parameter.

Oracle 9i example using OMF (Oracle Managed Files):

SQL> CREATE TEMPORARY TABLESPACE temp;

Default Temporary Tablespaces:

In Oracle 9i and above, one can define a Default Temporary Tablespace at database creation time, or by issuing an "ALTER DATABASE" statement:

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

The default Default Temporary Tablespace is SYSTEM. Each database can be assigned one and only one Default Temporary Tablespace. Using this feature, a Temporary Tablespace is automatically assigned to users. The following restrictions apply to default temporary tablespaces:

- The Default Temporary Tablespace must be of type TEMPORARY
- The DEFAULT TEMPORARY TABLESPACE cannot be taken off-line
- The DEFAULT TEMPORARY TABLESPACE cannot be dropped until you create another one.

To see the default temporary tablespace for a database, execute the following query:

SQL> SELECT * FROM DATABASE_PROPERTIES where PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';

All new users that are not explicitly assigned a TEMPORARY TABLESPACE, will get the Default Temporary Tablespace as its TEMPORARY TABLESPACE. Also, when you assign a TEMPORARY tablespace to a user, Oracle will not change this value next time you change the Default Temporary Tablespace for the database.

Other Considerations:

Some performance considerations for temporary tablespaces:

- Always use temporary tablespaces instead of permanent content tablespaces for sorting (no logging and uses one large sort segment to reduce recursive SQL and ST space management enqueue contention).
- Ensure that you create your temporary tablespaces as locally managed instead of dictionary managed (Use sort space bitmap instead of sys.fet$ and sys.uet$ for allocating space).
- Always use TEMPFILEs instead of DATAFILEs (reduce backup and recovery time + other advantages as described above)
- Stripe your temporary tablespaces over multiple disks to alleviate possible disk contention and to speed-up sorting operations (user processes can read/write to it directly).

Monitoring Temporary Tablespaces and Sorting:

Unlike datafiles, tempfiles are not listed in V$DATAFILE and DBA_DATA_FILES. Use V$TEMPFILE and DBA_TEMP_FILES instead.

One can monitor temporary segments from V$SORT_SEGMENT and V$SORT_USAGE

DBA_FREE_SPACE does not record free space for temporary tablespaces. Use V$TEMP_SPACE_HEADER instead:

SQL> select TABLESPACE_NAME, BYTES_USED, BYTES_FREE from V$TEMP_SPACE_HEADER;

TABLESPACE_NAME BYTES_USED BYTES_FREE
------------------------------ ---------- ----------
TEMP 52428800 52428800

SQL> select sum(free_blocks) from V$SORT_SEGMENT where tablespace_name = 'TEMP';
SQL> select inst_id, tablespace_name, total_blocks, used_blocks, free_blocks
from gv$sort_segment;

June 12, 2009

Good Design Thoughts


1. Encapsulate what varies --> identify the sections that vary and separate them from what stays the same
2. Favour composition over inheritance --> use "has-a" it is better than "is-a"
3. program to interface not implementations
4. Strive for loosely coupled designs between objects that interact (think mediator/observer)
5. Classes should be open for extension but closed for modification (think decorator pattern wrap around to extend)
6. Depend on abstracts not on concrete classes (an example would be factory method)
7. only talk to your friends (avoid having large number of classes coupled together)
8. dont call us, we will call you (template method - let superclass re-direct to subclasses)
9. A class should have only 1 reason to change

Inheritance vs Aggregation vs Composition


Inheritance - "Is A" Strongest Relationship

We depend on the functionalities of a Super Class

Aggregation - "Has A / Is Part Of" - Weaker Relationship

As shown in the example Aggregation occurs when the part of outlives the whole. e.g the listener instance could be alive even after WebServer instance is garbage collected


Aggregation Example ("has a"):



Composition - "Uses A" - Stronger Relationship

In a composition relationship the listener instance lifespan lasts till the WebServer instance is garbage collected.


Composition Example ("uses a"):







WSDL Styles Samples

==============================================
RPC LITERAL
==============================================








==============================================
RPC ENCODED
==============================================









==============================================
DOCUMENT LITERAL
==============================================












June 5, 2009

WSDL Styles

There are 5 types of WSDL styles.
  • RPC/Literal
  • RPC/Encoded
  • Document/Literal
  • Document/Encoded
  • Document Literal Wrapped Mode
Irrespective of the style differences, it can be applied to any technology.




WSDL Styles

Advantage

Disadvantage

RPC/Encoded

The WSDL is simple and straightforward

The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.

The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance.

Message cannot be easily validated as very few lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definition

RPC/encoded is not WS-I compliant.

RPC/Literal

The WSDL is still simple and straightforward

The operation name still appears in the message.

The type encoding info is eliminated.

RPC/literal is WS-I compliant.

Message cannot be easily validated as very few lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definition

Document/Encoded

NIL

Nobody follows this style. It is not WS-I compliant

Dcoument/Literal

There is no type encoding info.

Message can be validated with any XML validator. Everything within the soap:body is defined in a schema.

Document/literal is WS-I compliant,

The WSDL is getting a bit more complicated.It is not easily understood by humans

The operation name in the
SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.

WS-I only allows one child of the soap:body in a
SOAP message.

Document/Literal Wrapped Mode

There is no type encoding info.

Everything that appears in the soap:body is defined by the schema,
Message can be validated with any XML validator.

Once again, you have the method name in the
SOAP message.

Document/literal is WS-I compliant, and the wrapped pattern meets the WS-I restriction that the
SOAP message's soap:body has only one child.

The WSDL is even more complicated.

Reference: http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/