The large object (LOB) datatype allows us to hold and manipulate unstructured and semistructured data such as documents, graphic images, video clips, sound files, and XML files. The DBMS_LOB package was designed to manipulate LOB datatypes. Starting in Oracle Database 12c, LOBs can store large amounts of data with a maximum size of 128 TB depending on the database block size; a single table can have one or more columns of LOB datatypes, such as binary large object (BLOB), character large object (CLOB), national character large object (NCLOB), and BFILE. This article describes some of the problems that can happen when you have LOB segments in your environment and how to mitigate these problems.

In recent times, IT organizations have been tasked more and more with charting a course for writing new applications and migrating existing applications to a Java 2 Platform, Enterprise Edition (J2EE) environment. On the surface, this task might seem to be a matter of using predetermined methods, as was the case with the migration to client/server technology. However, one major aspect of J2EE is its variety and breadth. There is no one way to create a J2EE system; in fact, there are probably hundreds of combinations of J2EE technologies that could serve any one purpose. This makes the decision of selecting the proper technology combination daunting, especially if the J2EE environment is new to the organization.

Mastering the concept of selectors is a difficult part of learning jQuery. There are a number of methods to identify the right page element to act upon. In addition to the selectors mentioned in this blog, jQuery also provides the ability to traverse up and down the HTML tree using specific functions.

More detailed examples of selectors will be introduced as the blog details traversal methods in addition to other fundamental concepts and common features. Just like SQL, a good percentage of what you’ll ever need to do will already have an appropriate documented function.

As with any new technology or new venture, it's sensible to think through not only the benefits and opportunities that are presented, but also the costs and risks. Combine a relational database with a series of powerful and easy-to-use tools, as Oracle does, and the possibility of being seduced into disaster by its simplicity becomes real. Add in object-oriented and web capabilities, and the dangers increase. This article discusses some of the dangers that both developers and users need to consider.

Data storage and retrieval is a core element of most applications today. In the early days of software development, programmers wrote their own low-level code to accomplish this. However, they quickly realized that in each application they were essentially reinventing the wheel. Through the usual cycle of trial, error, and subsequent refinement a solution was developed: the data storage and retrieval engine was abstracted into a stand-alone data­base server with the clients connecting to it and sending requests in a custom language called SQL (Structured Query Language).

Your choice of an OLAP product from Oracle depends in part on your current IT infrastructure. If you are running an Oracle database as a data warehouse, the obvious solution is to add the Oracle OLAP option to your data warehouse. If you have an Oracle database as one source of data or if your organization has only non­Oracle data sources, your choice will depend on the criteria: purpose, buyer, typical end user, data management strategy, and architecture.