Everyone knows the basic features of sql*plus, but one underused feature that can make your scripts an order of magnitude more useful is the ability to store and reuse values, including values read from the database, in variables. This lets you use user-defined and database values not just in subsequent queries, but also in calls to other scripts and SQL*Plus's other functionality.
This article introduces Oracle XML DB features to the DBAs and Developers who are not actively working with XML. It offers a quick start to those who finds quite a lot of Oracle XML literature around, and who is not sure where to begin.
In the rapidly shifting world of database technology, one fact has always been, and will always remain, true: a great database is no good if it can easily be broken into. A faulty security plan is not just vulnerable to hackers; it opens your company to data theft, corruption, or even legal action.
One of the primary tests for DBMS reliability is what's known as the ACID test. ACID-compliant systems are as close as you can get to guaranteed not to lose your data. Essentially, as long as your database files are intact, you are guaranteed that your data is consistent. This is not true for non-ACID compliant systems. Non-ACID-compliant systems are vulnerable to data inconsistency, and generally aren't taken seriously for any application where data integrity is important. Now, in 10gR2, Oracle offers us the option to break its ACID compliance.
There are always a few topics in regards to writing SQL that always seem to come up more often than others. Querying data with case insensitivity is one of those topics. And Oracle has addressed this issue in many of their release. But in Oracle 10gR2 they have reached new levels. This article takes a dive into case insensitivity and how it is now handled in 10gR2. For the better!
DML error logging is a new feature for 10gR2. Have you ever tried to update 30 million records, only to have the update fail after twenty minutes because one record in 30 million fails a check constraint? Or, how about an insert-as-select that fails on row 999 of 1000 because one column value is too large? With DML error logging, adding one clause to your insert statement would cause the 999 correct records to be inserted successfully, and the one bad record to be written out to a table for you to resolve.
In this article Mark explais how one can drill from a "Discoverer for OLAP worksheet" to a "Discoverer Plus Relational worksheet" using Discoverer 10.1.2.
On our quest to learn about Oracle's Data Pump utility it has often been compared to the old export and import (exp & imp) utilities that we have all grown to love (or hate). This article is where where Data Pump takes a detour from these old utilities and begins to shine. This article will explore some of the export modes available and give examples on how to export selected object types and dependencies those objects have.
On our quest to learn about Oracle's Data Pump utility it has often been compared to the old export and import (exp & imp) utilities that we have all grown to love (or hate). This article is where where Data Pump takes a detour from these old utilities and begins to shine. This article will explore some of the export modes available and give examples on how to export selected object types and dependencies those objects
"I have a question about drilling from an OracleBI Discoverer for OLAP 10.1.2 worksheet to a Discoverer Plus Relational worksheet. When you pass values from an OLAP worksheet you pass either the dimension name or the dimension value to the associated parameter in the relational worksheet. Obviously, in OLAP this dimension is treated as an object, and we have no idea which level the user may have picked before he drills out. On the other hand, in the relational world, each level of the dimension would be split out as a separate parameter. Could you run through a simple example where you drill from an OLAP worksheet to a relational worksheet and show how this is done?"