My colleague Srini wrote an article on integrating SOA Suite with Oracle Internet Directory, which is available at http://redshift-au.blogspot.com/2009/05/soa-oid-integration.html

While I was over on Sergio's blog looking at the oracle-validated-rpm from a comment by Avi on my last blog entry, I saw another post that I think needs more publicity :-)

New Oracle Public Yum Server

If you're like me and have a bunch of machines that you muck around on and don't want to clutter up your ULN Systems page with servers you don't care about keeping up-to-date on security/bug fixes, why not take advantage of Oracle's newly released (OK, march 2009 but still...) public yum server.

Fantastically easy. Just go here to get started.

My Oracle Beehive test server I've just done the cheat sheet on was OEL 5.1, purely because I didn't have a DVD of the latest 5.3 OEL (I know, I'm slack...) But, now, thanks to this public-yum server and the simplest of commands:

# yum upgrade

I'm now running Oracle Enterprise Linux 5.3 (Carthage).

(FYI, for those following the cheat sheet from the other post, I had to rerun the SELinux text relocation mod after the upgrade.)

Gavin

Intro
Presuming you have to migrate your data to Exadata and you already did your capacity planning.

Then, probably, your next step is plan how to actually move your existing database to Exadata / HP Oracle DB-Machine (from now on called Exadata in this blog).

For this scenario, there are some small things to take care of.

My personal experience is that, preparing such a migration is all about knowing Oracle's MAA strategy. With that knowledge you know what options you have and don't have.

Off-line or On-line
First of al one has to decide whether the migration is 'off-line' or on-line.
'On-line' in this case is a matter of a couple of minutes downtime, you always have to switch from source database 'A' to target database 'B'.

Consider this time, for example, as the time it takes to switch over to a standby database.

'Off-line' is the most comfy solution, but only of course when the off-line window is large enough to migrate your data. In case of migrations to Exadata the data bulk you have to migrate will probably be 'large', so consider yourself lucky if you have a 'off-line' option and a window large enough to do the action.

For Exadata it is recommend to have an extent size that is a multiple of 4M. The ASM AU size should be 4M also. This is to make sure that at database level (for the extents) and at ASM level (for the AU's) at least 4M of contiguous chunks will be read. This is required to make Exadata perform best.

So, if you want to stick to this recommendation, you have to check the current size of your AU's and extents.
When you find out the size is not the recommend size then choice number two pops-up: will you do a 'logical' migration and stick to the recommendation or not and do a 'physical' migration. Of course, when your source system 'A' is not on ASM there isn't much AU's to check.

For the extents sizes the query should look like this:

select segment_name,
from dba_exents
where bytes < (4*1024*1024)
and owner = 'the name of the schema you are migrating';

If the extents already have the recommended size, you of course still can choose for a logical migration, but my personal feeling would be to do a physical migration in that case.

Physical migration
Physical migration to me means 'transferring the datafiles from platform A to platform B'. This situation leads us to new choices, like the choice of how to transfer the datafiles from A to B. This depends because platform A en B can both have a different architecture.

As we know Exadata/DB-Machine is based on Linux on Intel X86-64 and the source can be RISC (Sun Sparc, IBM P-series) for example (big endian). (where Intel and Itanium is little endian)

Fortunately Oracle has some good answers for this kind of questions:
- transportable tablespaces
- DBMS_STREAMS_TABLESPACE_ADM.PULL_TABLESPACES

To a certain level physical migrations can be done 'on-line' (or at least with as less downtime as possible). Think of dataguard for example.

As a last step; which solution you choose also depends on the infrastructure you are working in. Question you may ask yourself are:
- Do I have staging space on the source system
- Do I have network attached storage (NAS) available that I can use.
- Can this NAS be connected to source and target ?
- Are platform A en B actually on the same network anyway and
- If on the same network: can I safely use that network to tranfer my terabytes of data (not hurting the performance of other systems)

These are all realistic questions you have to deal with when you are talking about migrations.

Logical migration
You have to investigate into available solutions for logical migrations as well.
Before I continue I should first explain what my definition of logical migration is.

To me logical migration is 'exporting' the data from the source and 'importing' that into the target. Export can be any kind of tool such as: datapump, exp or even SQL*Loader or CTAS over a db-link. A 'logical' export can even be done 'on-line' if you would consider solutions like for example logical Standby database (same endian) or Oracle Streams (endian independent). 'Logical' migrations often need 'staging' (a location where you temporary dump you data). Note that datapump exports/imports can be done over the network without dumping anything to file.

As said, if you set yourself the target to change the extent sizes to the recommended values, you automatically end up in a logical migration if you not already have extents of this size.

There may be even more things to consider. For example.
- you need to build more then one replica of the source database on Exadata.
- you want to put as less load on the source system as possible because it's a highly critical production system.

When dealing with these kind of questions always know that Exadata can do the job quicker, because it so powerful.

Say for instance: you may realize exporting a 4TB database with datapump will cause to much load on the prodution system. But you still want to do a logical migration. For these kind of questions my answer would be to just transfer the datafiles to Exadata (and endian convert them if needed) and perform the export (expdp) and import (impdp) there. You probably don't even need to transfer the files, perhaps you can retrieve them from backup.

Exporting data with datapump is something you prefer to do in a read consistent way. For that think of the expdp arguments:
- flashback_time
- undo_rentention
And undo guarentee on tablespace level.

Note 1. Note that exporting lobs in a read consistent way can not be accomplished only by tuning the undo retention of the database. For lobs undo is a property of the column. In order to make sure the retention of these objects is set well you may have to alter your table first. For more information on this see "The application developers guide - Large objects"

Note 2. transferring or exporting indexes to Exadata seems rather useless to me. First, you have to consider yourself if the index is still needed in the first place. And if so, why not just recreate it on the target, since Exadata has probably got the muscles for it to recreate it in a small fraction of the time it took on your source database !

Summary
Migrations to Exadata are not more complicated then normal migrations. When dealing with large amount of data one should always think of a strategy before htting the keybord. As production environments have their limitations it proofed to be helpful to workout alternative scenarios as well. With expdp, transportable tablespaces, transportable databases, Streams, physical, logical standby databases, Oracle has all thinkable options available to migrate to this wonderful piece of database !

Helpful documents:
- Technical White Paper: Best Practices for Migrating to HP Oracle Exadata Storage Server
- Oracle Database High Availability Documentation - Features and Best Practices

Rene Kundersma
Oracle Expert Services, The Netherlands

Over the past few months in talking with many people in the IT industry, there seems to be a general misconception that because of all of the layoffs and redundancies in the IT industry that there should be hundreds of candidates to choose from for any vacancy that is open regardless of the specialisation or seniority of the role. While there are more "Active Job-Seekers" in the market looking for work we need to remember that companies look at both "Active" and "Passive" candidates when hiring not just one or the other.

A Manager may believe that because of the state of the economy there should be a long list of available people for an open role available immediately who are waiting by the phone for a role. While it may be easy to create a long list of Active Candidates who are available for a role, it does not mean that they are best suited for the position or that the position is best suited for them. Depending on the scope of search that we may work to, many Job-Seekers may not have the specific Oracle product experience, level of seniority, industry specialisation, etc.... that we may be looking for. That is not a knock on candidates who do not fit our scope of search, it just means that we need to look at other opportunities that may better fit their skills/experience and career plans.

Regardless of what stage of the cycle the economy is in (boom or bust), I think Recruitment should always be about quality of service and that means getting the right role for the right candidate and vice versa not just about getting X amount of resumes for Y number of open roles. From a candidates perspective this means finding the next ideal opportunity for a candidate, whether that means increased job responsibility, salary, location, etc... From a company perspective this means finding the ideal candidate who fits the scope of search that we need to work to (technical skills, seniority, location, etc....)

Out of 100% of the workforce, traditionally 15% of that workforce are actively looking for a new role, 40% are not looking for to move job/company and 45% are passive candidates who would move if the right opportunity presented itself to them.

There may be more Active Job Seekers in today's environment, but in my experience it is not just about whether a person is an Active or Passive Candidate, it is about finding the best person for the role. The people who may be best suited for a specific type of role may not necessarily be "Active Job Seekers". Companies often do not let their All-Star Performers go (although it does happen) and when we look to hire we want to hire All-Stars where their skills/experience and career plans fit the open role and the role we have fits what that person is looking for.

Whether you are an Active or Passive Candidate, if you are an All-Star and are thinking about whether an opportunity at Oracle may be the next step in your career, feel free to contact David Talamelli at david.talamelli@oracle.com to look at potential job opportunities with us.

The posts in this series assume that you have some level of familiarity with ODI. The concepts of Context, Topology, Logical Architecture, Physical Architecture and Variables are used here assuming that you understand them in the context of ODI. If you need more details on these elements, please refer to the ODI Tutorial for a quick introduction, or to the complete ODI documentation for more details.

In a previous post, we have discussed the notion of Context and how powerful it can be. There is a limit however. If you remember our discussion, each server, each schema on each server, have to be defined in the ODI Topology. Now imagine that you design processes that have to run on a large number of systems. The exact same code will be executed; only the physical location will be different. How about having thousands of systems where this code has to run. Who wants to maintain the connection information manually through a graphical interface? And maintain thousands of contexts while doing so?

Realistically, I think that contexts are fine up to about a dozen of environments. Beyond that, you need an environment that will be more dynamic. But we want to keep the benefits of having the exact same code on all systems, the flexibility of having a complete separation of the generated code and of the execution location. The solution? Use variables in Topology!

1. DEFINING THE ENVIRONMENT

Before jumping heads down in the usage of variables in Topology, I strongly recommend the creation of 2 contexts:
- A development context where all URL in topology point to an actual server, not using the variables. This will ensure that data can be viewed, and interfaces can be tested without any concerns regarding the variables resolution;
- The dynamic context (similar to what will be used in QA and Production) will use the variables in topology to name the servers, port numbers, user names for the connections, etc. The package will assign the appropriate values to the variable and run the interfaces on the appropriate servers. This context will only be used to validate that the processes defined in the Development context work properly when we use the variables.

Independently from ODI, we will need a table to store the values that will be used for the Topology variables. For this example, will be simply use different server names. Keep in mind that other topology parameters can be set using this same technique.

The table for our structure will contain the server names, as well as the name of an ODI agent: with many processes running concurrently, it is better to assign pools of servers to different agents. We will use the following structure:

create table ODI_SERVERS (
SERVER_NAME varchar(50),
AGENT_NAME varchar(50)
);

Loading this table is not part of the description we have here. If you have a list of servers available somewhere, ODI would be the perfect tool to load your table though…

2. SETUP: CREATION OF THE VARIABLE AND TOPOLOGY DEFINITION

2.1 Creation of the Variable
Details on the creation of a variable can be found here . We will simply review the main steps here.

Create a new variable called ServerName.
The data type is Alphanumeric.
You can set the default value to localhost.
You can use the Description field to describe the variable.
In the Refreshing tab, select the logical schema that hosts your ODI_SERVERS table and enter the following query:

select SERVER_NAME from ODI_SERVERS

Note: for more flexibility in the execution of your code, you should never hard-code a schema name – nor assume that the login used to connect to a server defaults to your schema name. Best practice in the example above would be to let ODI complete the table name with the schema name by using the following syntax:

select SERVER_NAME from &lt%=odiRef.getObjectName(“L”, “ODI_SERVERS”, “D”) %&gt

2.2 Definition of the Topology

2.2.1 Contexts

To get more details on the creation of contexts, please check out this example. If you already know your way around Topology, create the following two contexts: Development and Dynamic

2.2.2 Development Server: Hardcoded Values

In topology, define one of the servers that you want to access. We will use this server for our development work, and ignore the variables for now: enter the parameters as usual for the definition if this server:

Make sure to test the connectivity to validate your parameters. Define a physical schemas as usual under this data server. Map it to the logical schema ORA_DYNAMIC_SERVER for the Development context.

Note: you will have to create the logical schema to perform this mapping.

2.2.3 Dynamic Server: Using the Variables

For the dynamic contexts, we will use the variable as part of the connection string (aka the JDBC URL). Instead of typing the actual hostname, type the variable name, including the CODE of the project where the variable was created (or GLOBAL for a global variable).

URL example for Oracle:
jdbc:oracle:thin:@#PROJECTCODE.ServerName:1521:ORCL

This physical server will be considered as the dynamic server. Map its physical schema to the logical schema defined in the previous step, in the Dynamic context this time.

3. EXECUTING CODE IN THE DYNAMIC CONTEXT

Your code will work as usual in the Development environment: you can validate your transformations, your processing logic and processing time. When you will want to use the Dynamic context though, a few more steps will be required.

3.1 Connection to the Databases

The ODI agents are in charge of the connection to the databases, sources and targets. At the beginning of the execution of a process, the agent will connect to the Master Repository to retrieve the Topology information. Then it will connect to the databases, generate the code, and send that code to the databases. This represents a challenge in our case, since we need to set a value for our variables before the agent connects to the databases: we cannot set the value of our variables in the package that will be executed...

3.2 Setting the Values for Topology Variables

The solution will be to pass these values as parameters to the process, so that the values are known to the agent before it establishes the connection. You can set the values no matter how you start the scenario: from a command line interface, from another scenario or from an ODI procedure, from a web service or from a Java API. Remember to declare your variables at the beginning of your package to make sure that the value of the parameters gets properly stored though!

For more details on how to pass parameters to an ODI process, you can check out this previous blog entry.

4. UNDERSTANDING POTENTIAL ERRORS

- Make sure that the variable name is properly spelled in Topology (Variable names are case sensitive
- Make sure that the variable is declared at the beginning of your package
- Make sure that the variable is referenced with its project CODE (not the project name) in Topology

For more information on ODI contexts, please refer to the ODI Users Guide (part of the Documentation Library that comes with the ODI installation), in particular the entry "What is the Topology? "

All Screenshots were taken using version 10.1.3.5 of ODI. Actual icons and graphical representations may vary with other versions of ODI.

In Part 1 this short Tangible Benefits of E2.0 series, we covered the bad news around E2.0 and ROI and Adoption. Now in Part 2, we cover the good news from the research angle.

In Part 3 will will cover the good news from the anecdotal (case study) angle.

Good news comes in two flavors, research (proof/support) and anecdotes. Research is important because it seeks to remove extraneous factors to get to the heart of the matter. Where E20 is concerned, such research is important because it removes contributing factors that may skew reports of success. Working with your 2 best friends on an E20 project that you are all passionate about may yield success but it may not be reproducable for others. That ability to assure or reasonably predict success (or failure) is what research is designed to show.

So is there any scholarly, quantitative and qualitative (both are important) research that helps bolster the case for Enterprise 2.0? Yes. And more is coming in every month (with the academic publishing cycles). I will point out several such studies.

The Journal of Product Innovation Management (issue 26) from March of this year has 3 scholarly articles that all directly consider or indirectly touch upon the benefits of Enterprise 2.0 technology and approaches to collaboration. These are quantitative and qualitative scholarly research papers, peer reviewed and with all the trappings of academe.

One article presents evidence that frequent and open communication enhances team collaboration.

Another finds that technologically enhanced synchronous and asynchronous communications (think chat, team spaces, discussion boards, shared calendars, web conferences and file sharing all on a common platform) creates a deeper sense of shared identity among cross functional team members (think people with different managers). This shared sense of identity is critical to achieving common purpose and being able to have super-speed collaboration and innovation.

The third article goes another step further in exploring how everything from social networks to water cooler talk to going out to the pub together facilitates knowledge sharing. Such knowledge sharing is key to discovering novel ideas and innovative solutions.

Don't panic, we're not turning into a BIEE blog, I have been doing dome work with it lately and could not find the following nugget out there. Colleagues on an internal list helped out with my request - it was a simple one but I wanted to record it for posterity.

As many of you have seen you can generate totals and sub-totals in your BIP templates quite easily, you can also embed fields into the total label text.

To get the customers name in the total text, its just a case of copy and pasting the customer name field into the table cell.

I needed to do the same in a BIEE pivot table. Not quite so obvious but doable, once I got some help from my friends, ooooh I get by with a little help from my friends ... danged Guitar Hero! I dont even like the Beatles, for a Brit, sacrilege I know.

Building out the pivot you can see that if you set a total for the group you get XXXXX Total.

the dialog to customize the total string is tucked away a little. Click the total icon again and select Format Labels

This will pop the dialog

You can now enter the text you want, the '@' character will be replaced at runtime with the actual group value.

The pivot now renders with the required text.

Although Coherence is often used to manage Servlet session state for J2EE applications – without changing the application code – it can also be used by J2EE Web applications to access data in a simple cache. This article discusses how to do this and how you should package your Web application so that it is a completely self contained Coherence client. Although the principles should work for all J2EE applications servers you will not be surprised to learn that I have only tested this on WebLogic Server (10.3).

The Web application outlined below is a Coherence*Extend Client, that means that it connects over a TCP/IP connection to the Coherence cluster (which uses UDP for inter-node communications) holding the cache data. A Proxy service run either on one or more of the cache nodes (or in a separate JVM) is used to pass requests and response between the client and the Coherence cluster – in a similar fashion to the way an Oracle Database listener works.

Note, the client could also be a Coherence Data Client, which means that the Web client would actually be part of the Coherence cluster. In this case the client would need to be ‘storage disabled’ through a system property or through the tangosol-coherence-override.xml configuration file. This means that although it will be part of the cluster it will not actually hold any data, so when the client is deployed or un-deployed there will be no cluster overhead re-organising cache data.

Accessing the configuration files

You really have a choice here. put them in the packaged Web application or reference them externally through the CLASSPATH or via a system property. Here I am going to package them with the Web application to make is completely self-contained. The code to do this is shown below:

 56    /** 57     * <p>Reference to ConfigurableCacheFactory that can be used to 58     * create a cache.</p> 59     */ 60    private ConfigurableCacheFactory factory = null; 61   62    /** 63     * @inheritDoc 64     */ 65    public void init(ServletConfig config) 66      throws ServletException 67    { 68      super.init(config); 69      // Create DefaultConfigurableCacheFactory using cache configuration file 70      // in classes dir 71      factory = 72          new DefaultConfigurableCacheFactory("/config/cache-config.xml", 73                                              getClass().getClassLoader()); 74    }

Here a DefaultConfigurableCacheFactory is used to read the configuration file used to setup the Coherence client parameters. All the configuration files that the Coherence client needs will be stored in the /WEB-INF/classes/config directory of the Web application. These are:

• cache-config.xml indicating where the Coherence cluster can be contacted

   

• pof-config.xml indicating the mapping between client and server objects. As both the client and server are Java only one object needs to be defined.

   

   

• tangosol-coherence-override.xml encapsulated many of the Coherence settings the are often specified as system properties.

The cache is accessed in the doGet(..) method of Servlet  as shown below:

 76    /** 77     * @inheritDoc 78     */ 79    public void doGet(HttpServletRequest request, 80                      HttpServletResponse response) 81      throws ServletException, IOException 82    { 83      // Create response 84      response.setContentType(CONTENT_TYPE); 85      PrintWriter out = response.getWriter(); 86      out.println("<html>"); 87      out.println("<head><title>CoherenceServlet</title></head>"); 88      out.println("<body>"); 89      // Get Coherence cache date 90      NamedCache cache = 91        factory.ensureCache("stock-cache", getClass().getClassLoader()); 92      // Get Stock object from cache 93      Stock s = (Stock) cache.get("ORCL"); 94      double price = 0; 95      if (s != null) 96      { 97        price = s.getPrice(); 98      } 99      // Output stock price in response100      out.println("<p>The latest Oracle Stock Price is: <b>" + price +101                  "</b></p>");102      out.println("</body></html>");103      out.close();104    }

The other source file that needs to be deployed with the Servlet is the Stock object that is being cached – a separate Java application is used in this scenario to add a Stock object to the “stock-cache” and then continually update it. This means that if the content displayed by the Servlet is refreshed in a browser a new stock price will appear.

Packaging it all up

To package it all up you naturally wrap the Servlet and Stock classes – along with the Coherence configuration files and supporting web configuration files – in a WAR file. This WAR file then needs to be wrapped in an EAR file with the coherence.jar file and a reference to this JAR in the MANIFEST.MF file as follows:

Class-Path: lib/coherence.jar

Note in the Eclipse project the coherence.jar file is in the base dir of the EAR file. The complete structure of the EAR file is shown below:

When the application is deployed and run you should see something like this which if you keep refreshing should change.

Summary

That’s it. You should now be able to create a cache, put some data into it and then access it from the above Servlet. The full source code for this example can be found here. There is a JDeveloper 11g project and an Eclipse Eurpoa project. There are some batch files to run-up a cache server and a separate client to insert and update Stock data, but unfortunately they are only in JDeveloper project – at the moment. See the readme.txt file for details of how to set things up.

(DOAG = Deutsche ORACLE Anwendergruppe e.V.)

Rückblick:
Auf der DOAG Konferenz 2008 in Nürnberg konnten wir erstmals einige unserer Hochschul-Mitglieder als Referenten vermitteln. Es wurden insgesamt 9 interessante Fachvorträge zum Thema "Einsatz von Oracle in der Hochschule" in das Veranstaltungsprogramm eingebunden.

Darüberhinaus hatte die DOAG eine spezielle "Students' Community" eingerichtet, wo Studierende und ausstellende Unternehmen an einem eigenen Stand zwecks Praktikumsplätze, Bachelor-/Master-Arbeiten Kontakte knüpfen und sich austauschen konnten. Studierenden wurde ebenfalls die Möglichkeit geboten, sich als Konferenzhelfer zu bewerben und im Gegenzug von der DOAG einen Konferenzausweis zu bekommen. Dieses Angebot wurde von ca. 30 Studierenden angenommen und fand eine sehr positive Resonanz.

Aktuell:
Als Fortführung dieser Students' Community wurde die DOAG Hochschul-Community gegründet und nun offiziell gelauncht.
"In dieser Gruppe bündelt die DOAG ihre Aktivitäten zur Integration der Hochschulen in das Netzwerk der Oracle-Community", so Dr. Dietmar Neugebauer, Vorstandsvorsitzender der DOAG. Die DOAG stellt dazu eine Plattform für die Zusammenarbeit von Professoren, Studenten, Oracle, Oracle-Partnern und Oracle-Anwendern zur Verfügung.

Weitere Informationen sind auf der DOAG Hochschul-Community-Seite zu finden.

Die diesjährige DOAG-Konferenz findet vom 17.-19. November 2009 wieder in Nürnberg statt. Studierende können sich mit spannenden Bachelor-, Master- oder Forschungs-Arbeiten um einen Vortrag bewerben, oder aber an der Konferenz als Helfer aktiv teilnehmen.