It's been over a year since my first and very enthusiastic ASM article titled "Optimizing Oracle 10g on Linux Using Automated Storage Management", still currently available at:

• www.quest.com/landing/default.aspx?Id=66
• www.quest-pipelines.com/newsletter-v5/0104_A.htm
• www.oracle.com/technology/oramag/webcolumns/2003/techarticles/scalzo_asm.html

Since then, quite a lot has changed in terms of the software technologies now available:

• Redhat released Advanced Server 4.0 built on the 2.6 kernel
• Redhat released with AS 4.0 a vastly improved LVM with GUI
• Redhat released the Global File System (and now part of Fedora)
• Oracle released version 10.2.0.1 of the database (10g release 2)
• Oracle released version 2.0 of the ASM kernel driver and libraries
• Oracle released version 2.0 of the Oracle Cluster File System

As you can see, the software technology landscape has so extensively changed as to reopen the entire ASM debate. In my first ASM paper I simply assumed either people would be utilizing ASM or not – without considering RAC usage ramifications. What numerous people have told me this past year at shows, conferences and on-site visits is that while ASM makes obvious sense for RAC environments, they also desired to know whether ASM was in fact a viable alternative for non-RAC environments. Specifically, does ASM perform as well as Linux file systems using a Logical Volume Manager?

Of course that's a challenge far too enticing to pass up – especially when there are tools like Quest's Benchmark Factory that make such tests trivial. So on to the races!

Oracle server uses locks to provide concurrent access to shared resources whereas it uses latches to provide exclusive and short-term access to memory structures inside the SGA. Latches also prevent more than one process to execute the same piece of code, which other process might be executing. Latch is also a simple lock, which provides serialize and only exclusive access to the memory area in SGA. Oracle doesn’t use latches to provide shared access to resources because it will increase CPU usage. Latches are used for big memory structure and allow operations required for locking the sub structures. Shared resources can be tables, transactions, redo threads, etc. Enqueue can be local or global. If it is a single instance then enqueues will be local to that instance. There are global enqueus also like ST enqueue, which is held before any space transaction can be occurred on any tablespace in RAC. ST enqueues are held only for dictionary-managed tablespaces. These oracle locks are generally known as Enqueue, because whenever there is a session request for a lock on any shared resource structure, it's lock data structure is queued to one of the linked list attached to that resource structure (Resource structure is discussed later).

DB2 is used by 100 percent of Fortune 100 firms and 80 percent of the Fortune 500. As such, it is an important component of the applications that drive the most significant businesses in the world.

Dynamic business requirements force constant change and overwhelming complexity on the typical IT environment. Regulatory compliance issues, time-to-market pressures, and industry consolidations cause turbulence as IT struggles to keep systems in sync with business demands. But managing systems becomes even more troublesome as technology trends evolve. Examples of these trends include business intelligence, e-commerce, and rapid software versioning.

DECLARE
 TYPE clientele IS TABLE OF VARCHAR2 (64);
 client_list_12 clientele :=
 clientele ('Customer 1', 'Customer 2');
BEGIN 
 IF 'Customer 1' MEMBER OF client_list_12
 THEN
 DBMS_OUTPUT.put_line ('Customer 1 is in the 12 list');
 END IF;
 IF 'Customer 3' NOT MEMBER OF client_list_12
 THEN
 DBMS_OUTPUT.put_line ('Customer 3 is not in the 12 list');
 END IF;
END;
/

Click here for more.
 

Interested in learning more tips and techniques for SQL Server? "In A Nutshell" is what you are looking for. Kevin Kline, author of O'Reilly's "SQL in a Nutshell" and "Transact-SQL Programming" and President of The Professional Association for SQL Server, offers tips, techniques and much more.  Updated numerous times a week, there is always valuable material to be had!

Click here to see what Kevin is up to in the SQL Server world.

The information_schema database consists of a set of table-like objects (actually, system views), exposing metadata in a relational format. This allows one to execute arbitrary SELECT statements to retrieve or to format metadata. Metadata is available only for those objects that are accessible to the current user. The metadata is automatically maintained by the server, and the information_schema database is automatically created upon MySQL installation.

In MySQL versions prior to 5.0.2, virtually the only way to obtain metadata is through the MySQL specific SHOW syntax. The possibilities to control the output of the SHOW commands are limited to filtering for data of interest, whereas the information schema allows us to use the full set of relational operations defined by the SQL language. This allows DBA's and application developers to retrieve exactly the data they need to port applications, generate maintenance scripts or document database structure.