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?"
Oracle recommends that RAC databases be managed with srvctl, an Oracle-supplied tool that was first introduced with 9i RAC. The 10g version of srvctl is slightly different from the 9i implementation. In this article, we will look at how -- and why -- to manage your 10g databases with srvctl.
In this article, Mark explains how the SQL MODEL clause can be used to generate rather complex financial statements.
Since we are all familiar with Oracle’s original export (exp) utility, and in my opinion Data Pump will be replacing exp soon, I thought it would be good to start off getting familiar with this utility by some relatively simple Data Pump exports (expdp) that are similar to the way we have used exp in the past. In particular the FULL export.
One of the most powerful features of the multidimensional engine behind analytic workspaces is the ability to create formulas. Formulas, or "calculated measures" as they're referred to in AWM10g, are measures that are derived from other measures. Using AWM, you can create simple formulas that reference other measures in a cube, allowing you for example to create a "margin" measure derived from sales and costs measures. If you're an old Express hand though, you'll know that this simple type of formulas is just the tip of the iceberg, and what you often used to end up doing was creating for example a three dimensional formula based on measures from four and five dimensional variables, rolling up unneeded dimensions and pulling in variables held in what would now be referred to as "cubes".
DBAs wanting to create a 10g Real Applications Cluster face many configuration decisions. One of the more potentially confusing decisions involves the choice of filesystems. Gone are the days when DBAs simply had to choose between "raw" and "cooked". DBAs setting up a 10g RAC can still choose raw devices, but they also have several filesystem options, and these options vary considerably from platform to platform. Further, some storage options cannot be used for all the files in the RAC setup. This article gives an overview of the RAC storage options available.
When Oracle released RMAN (Recovery Manager) in Oracle 8 they changed the way databases can be backed up and recovered in the event of disaster. Unfortunately, Oracle shops have been slow to embrace RMAN often times because the change required a leap of faith into the new backup / recovery process as well changes to scripts, procedures, etc. This article will introduce the reader to RMAN and explain why every DBA should use it.