Learn CA Gen Every Day

This is pointers/place holders for the learning on CA gen http://www.ca.com/in/products/detail/ca-gen.aspx
and may expand latter on
1.DTU cannot trace when dialog flow happens with display option
2. Dialog link flow 

DP

About DP

Oracle data export guide

http://searchoracle.techtarget.com/generic/0,295582,sid41_gci1342129_mem1,00.html

SOA

The Benefits of a Service-Oriented Architecture

Even if you don't have your ear to the ground, the far-off rumble is a reminder that services are coming. First, there was the web services wave. Recently, Microsoft created another groundswell with the introduction of Indigo at the last PDC. Although the future may still be a year or more off, there is no denying it: the programming world is about to enter the era of services.

Currently, the big architectural push is towards a service-oriented architecture (SOA). While the term sounds impressive, it is important to understand both what an SOA is and how it can benefit a development team. There are a number of different links available that describe the components and concepts behind SOA, including at ondotnet.com, xml.com, and microsoft.com. Given this wealth of information, it would be redundent to cover it here (but perhaps in another article ;). Instead, I'd like to focus on some of the benefits that accrue to those who choose to follow the SOA path.

Even with that slough-off of responsibility for the concepts of SOA, it is still necessary that we have a common reference as the jumping off point for a discussion of benefits. So briefly, a service-oriented architecture is a style of application design that includes a layer of services. A service, from this limited perspective, is just a block of functionality that can be requested by other parts of the system when it is needed. These services have a published as set of methods, known as an interface. Usually, each interface will be associated with a particular business or technical domain. So there could be an interface used for authentication and another interface used to create and modify a sales order. The details of the provided functionality are not important for this article so much as the relative location of the code that implements the functions.

A word of warning to developers who are new to the services architecture (or an object-oriented environment as well). SOA is as much about a mind set as it is about coding. In order to reap any of the benefits of SOA, the application must be designed with services in mind. It is difficult, if not impossible, to convert a procedural application to services and still achieve anything remotely close to what can be gained from baking services in from the beginning. That having been said, there are usually elements of procedural applications which can be 'servicized'. This is the equivalent of refactoring the applications looking for common functionality.

And so, on to the benefits. In each case, we are talking about development teams that embrace SOA to the point that most of the development effort is focused on the creation and utilization of services.

Loosely Coupled Applications

Strictly speaking, coupling is the level of impact that two modules have on one another. From a developer's perspective, it is the odds that a change in one module will require a change in another. We have all seen tightly coupled systems. These are applications were developers are afraid to touch more procedures than necessary because they might cause the result of the application to break. The goal, whether we know it or not, is to create a loosely coupled environment. And services go a long way towards making such an environment a reality.

Consider for a moment what I consider to be the epitome of loosely coupled systems: a home entertainment system (Figure 1).





Figure 1 - A Loosely Coupled Home Entertainment System

Here are a whole bunch of different components (the exact number depends on how into electronic gadgets you are), frequently created by different manufacturers. The while the user interface can get complicated, between the devices the connections are quite simple. Just some wires that get plugged into standard sockets. Need to replace one of the element? No problem. Remove the wires connecting Component A to the system. Take Component A away. Insert Component B. Put the wires into the appropriate sockets. Turn things on and go. Talk about loosely coupled.

In software, a loosely coupled environment allows for changes to be made in how services are implemented without impacting other parts of the application. The only interaction between the application and the services is through the published interface. Which means that, so long as the interface doesn't change, how the functions are implemented are irrelevant to the calling application. Strict adherance to such an approach, an approach which is strongly enforced by SOA, can significantly reduce development by eliminate side-effect bugs caused by enhancements or bug fixes.

Location Transparency

Another benefit accrued through the use of interfaces and the loosely coupled structure imposed by SOA is location transparency. By the time we're done, it will seem like many of the benefits achieved with SOA will come from this same place (interfaces, that is). In this instance, location transparency means that the consumer of the service doesn't care where the implementation of the service resides. Could be on the same server. Could be on a different server in the same subnet. Could be someplace across the Internet. From the caller's perspective, the location of the service has no impact on how a request for the service is made.

It might not be immediately obvious why location transparency is a good thing. And, in the most straightforward of environments, it doesn't really make a difference. However as the infrastructure supporting a set of web service becomes more complicated, this transparency increases in value. Say the implementing server needs to be moved. Since the client doesn't care where the service is, the change can be made with no change required on the client. In fact, the client can even dynamically locate the implementation of the service that offers the best response time at the moment. Again, not something that is required for every situation, but when it's needed, location transparency is certainly a nice tool to have in your arsenal.

Code Reuse
Functional reuse has been one of the holy grails for developers since the first lines of code were written. Traditionally, however, it has been hard to achieve for a number of reasons. It is difficult for developers to find a list of the already implemented functions. Once found, there is no document that describes the expected list of parameters. If the function has been developed on a different platform or even in a different language, the need to translate (known technically as marshaling) the inbound and outbound values is daunting. All of these factors combine to make reuse more of a pipe dream than a reality.

The full-fledged implementation of a SOA can change this. The list of services can be discovered dynamically (using UDDI). The list of exposed methods, along with the required parameters and their types, are available through a WSDL document. The fact that even complex data structures can be recombined into a set of basic data types held together in an XML document makes the platform and language barrier obsolete. When designed and implemented properly, SOA provides the infrastructure that makes reuse possible. Not only possible, but because it is easy to consume services from either .NET or even the more traditional languages, developers are much more likely to use it. And ultimately, the lack of developer acceptance has always been the biggest barrier of all.

Focused Developer Roles
Almost be definition, a service-oriented architecture forces applications to have multiple layers. Each layer serves a particular purpose within the overall scope of the architecture. The basic layout of such an architecture can be seen in Figure 2.





Figure 2 - Some Layers in a SOA

So when designing an application, the various components get place into one of the levels at design time. Once coding starts, the someone is actually going to create the component. The skills necessary to develop each of the components are going to differ and the type of skill required will depend on the layer in which the component is placed. The data access layer requires knowledge of data formats, SQL, ADO.NET. The authentication layer could utilize LDAP, WS-Security, SHA or other similar technologies. I'm sure you get the idea enough to put it in play in your own environment

The benefit of this separation are found in how the development staff can be assigned to the various tasks. Developers will be able to specialize in the the technologies for a particular layer. As time goes by, they will be experts in the complex set of skills used at each level. Ultimately, by focusing the developers on a particular layer, it will even become possible to include less skilled programmers in a paired or a mentoring environment. This doesn't eliminate the need for an overarching technical lead, but it certainly decreases the reliance of a company on experienced generalists.

Greater Testability
It has been a few paragraphs since they were mentioned, but the fact that services are only access through their interfaces is the reason for this benefit. The fact that services have published interfaces greatly increases their testability.

One of the nicest tools in recent years for assisting with the testing process is NUnit. A .NET version of the JUnit, NUnit allows for the creation of a test suite. The test suite consists of a number of procedures, each of which is designed to test one element of an application or service. NUnit allows the suite to be run whenever required and keeps track of which procedures succeed and which fail. My experience with NUnit is that it makes the process of developing a test suite incredibly simple. Simple enough that, even with my normal reticence for testing, I no longer had an excuse not to create and use unit tests.

The fact that services publish an interface makes them perfect for NUnit. The test suite for a particular service knows exactly what methods are available to call. It is usually quite easy to determine what the return values should be for a particular set of parameters. This all leads to an ideal environment for the 'black box' testing that NUnit was developed for. And whenever a piece of software can be easily tested in such an environment, it inevitably results in a more stable and less bug prone application.

Parallel Development
There is another side benefit that arise both from the increased testability (and tools such as UNint) and the division of components into layers. Since the only interaction that exists between services is through the published interfaces, the various services can be developed in parallel. At a high level, so long as a service passes the NUnit test for its interface, there is no reason why it would break when the various services are put together. As such, once the interfaces have been designed, development on each of the services can proceed independently. Naturally, there will need to be some time built into the end of the project plan to allow for integration testing (to ensure that the services can communicate properly and that there was no miscommunication during development). But especially for agressive project timelines, parallel development can be quite a boon.

Better Scalability
This particular benefit refers to the ability for a service to improve its response time without impacting any of the calling applications. It is an offshoot of the location transparency provided by SOA. Since the calling application doesn't need to know where the service is implemented, it can easily be moved to a 'beefier' box as the demand requires. And if the service is offered through one of the standard communication protocols (such as HTTP), it is possible to spread the implementation of the service across a number of servers. This is what happens when the services is place on a web farm, for example. The reasons and techniques for choosing how to scale a service are beyond the scope of this article (although they will be covered in a future one). It is sufficient, at this point, to be aware that they are quite feasible.

Higher Availability
Location transparency also provides for greater levels of availability. Read the section on scalability and web farms for the fundamental reason. But again, the requirement to utilize only published interfaces brings about another significant benefit for SOA.

Building Multi-Service Applications
I've always described this benefit as the “Star Trek Effect“. The idea can be seen in many Star Trek episodes, both new and old. In order to solve an impossible problem, the existing weapon systems, scanning systems and computer components need to be put together in a never-before seen configuration.

“Cap'n. If we changed the frequency of the flux capacitor so that it resonated with the dilithium crystals of that alien vessel, our phasers might just get through their shields. It's never been done before, but it might work. But it'll take me 10 seconds to set it up“

Try reading that with a Scotish accent and you'll get my drift. Here are people working with services to the level that no programming is required to be able to put them together into different configurations. And it is the goal that most service-oriented architects have in mind, either consciously or subconsciously, when they design systems. And, although we are not yet at the Star Trek level of integration and standardization, SOA provides a good start.

Summary
And that's all SOA is, after all. A good start. But it is a start that is necessary to gain the benefits I've just run through. Sure it takes a little longer to design a service-based application. Not to mention creating all of the infrastructure that needs to surround it, assuming that it will be production quailty. However in the long run, the benefits start to play out.

Now I'm not naive enough to believe that we haven't heard this song before. It is basically the same song that has been playing since object-oriented development was first conceived. We heard it with COM. Then it was DCOM. Now it's web services and SOA. Why should be believe that this time will be different from the others?

I can't offer any reason in particular in answer to that very astute question. Honestly, SOA feels different than COM and OO. Perhaps that is because we've already seen the problems caused by COM, CORBA, etc and they are addressed by web services. Perhaps it is because there is now a common language that can be used across platforms (XML). Perhaps it is the level of collaboration between the various vendors regarding service-based standards. But to me at least, all of these items make me much more optimistic that this time we are heading down the right path.

copied from:http://objectsharp.com/cs/blogs/bruce/pages/235.aspx

List of additional steps to do for cleaning the system completely after uninstall using universal installer.
# Stop any Oracle services that have been left running.
Start->Settings->Control Panel->Services
Look for any services with names starting with ‘Oracle’ and stop them.
# Run regedit and delete the following keys (some may have slightly different names in your registry):
HKEY_CURRENT_USER\SOFTWARE\ORACLE
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet Services\EventLog\Application\Oracle.oracle
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet Services\OracleDBConsole
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet Services\Oracle10g_home
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet Services\OraclService
Note that the services control panel will still show the old services until you reboot.
# Delete the Oracle home directory
C:\Oracle
# Delete the Oracle Program Files directory:
C:\Program Files\Oracle
# Delete the Oracle Start Menu shortcuts directory:
C:\Documents and Settings\All Users\Start Menu\Programs\Oracle*
Where * indicates the name of your install. Look for and remove all Oracle directories from that location.
# Remove Oracle refereces from the path. To edit your path go to:
Start->Settings->Control Panel->System->Advanced->Environment Variables
Edit both of the environment variables user PATH and system PATH. Remove any Oracle references in them.
# Remove Oracle.DataAccess and any Polic.Oracle files from the GAC which is at:
C:\Windows\assembly\

This is a collection of 15 FAQs for Oracle DBA on creating Oracle database instances manually using CREATE DATABASE statement. Items in this FAQ collection are organized together to form a complete tutorial guide on creating a new database instance manually. Topics included in this FAQ are:
How To Create an Oracle Database?
How To Create an Oracle Database Manually?
How To Select an Oracle System ID (SID)?
How To Establish Administrator Authentication to the Server?
How To Create an Initialization Parameter File?
How To Connect the Oracle Server as SYSDBA?
How To Create a Server Parameter File?
How To Start an Oracle Instance?
How To Start a Specific Oracle Instance?
How To Start Instance with a Minimal Initialization Parameter File?
How To Run CREATE DATABASE Statement?
How To Do Clean Up If CREATE DATABASE Failed?
How To Run CREATE DATABASE Statement Again?
How To Create Additional Tablespaces for an New Database?
How To Build Data Dictionary View an New Database?
Sample scripts presented in this FAQ are based Oracle 10g Express Edition (XE) for Windows. The script in Step 7 failed due some unknown reason. But it might work on Oracle 10g Standard Edition.
How To Create an Oracle Database?
There are two ways to create a new database:
• Use the Database Configuration Assistant (DBCA) to create a database interactively.
• Use the CREATE DATABASE statement to create a database manually.
How To Create an Oracle Database Manually?
Based on Oracle's Administrator Guide, there are 11 steps to create a database with the CREATE DATABASE statement:
• Step 1: Decide on Your Instance Identifier (SID)
• Step 2: Establish the Database Administrator Authentication Method
• Step 3: Create the Initialization Parameter File
• Step 4: Connect to the Instance
• Step 5: Create a Server Parameter File (Recommended)
• Step 6: Start the Instance
• Step 7: Issue the CREATE DATABASE Statement
• Step 8: Create Additional Tablespaces
• Step 9: Run Scripts to Build Data Dictionary Views
• Step 10: Run Scripts to Install Additional Options (Optional)
• Step 11: Back Up the Database.
Other items in this FAQ collection will follow those steps to help you creating a new database manually from beginning to end.
How To Select an Oracle System ID (SID)?
This is Step 1. If you are planning to create a new database, you need to select an Oracle System ID (SID). This ID will be used to identify the new Oracle database and its Oracle instance. SID must be unique if you want to run multiple databases on a single server.
Let's set SID for the new database to be: FYI.
How To Establish Administrator Authentication to the Server?
This is Step 2. There are two ways to establish administrator authentication to a new database.
• Use a password file.
• Use operating system (OS) authentication.
Using OS authentication is easier on Windows system. If you used your own Windows user account to install Oracle server, it will put your Windows user account into a special Window's user group called SYSDBA. This Window's user group will be fully trusted by Oracle server with SYSDBA privilege.
To continue with other steps, make sure you logged into the Windows system with a user account in the SYSDBA group.
How To Create an Initialization Parameter File?
This is Step 3. To run an Oracle database as an Oracle instance, you need to create an initialization parameter file, which contains a set of initialization parameters.
The easiest way to create an initialization parameter file to copy from the sample file provided by Oracle. You can do this in a command window as shown below:
>cd $ORACLE_HOME

>copy .\config\scripts\init.ora .\database\initFYI_ini.ora

>edit .\database\initFYI_ini.ora
(replace XE by FYI)
In this example, only the SID is changed from XE to FYI. All other parameters are maintained as is.
How To Connect the Oracle Server as SYSDBA?
This is Step 4. The best way to connect to the Oracle server as an administrator is to use SQL*Plus. You need to run SQL*Plus with /nolog option and use the CONNECT with blank user name, blank password and AS SYSDBA option. Here is a sample session:
>cd $ORACLE_HOME
>.\bin\sqlplus /nolog

SQL> CONNECT / AS SYSDBA
Connected.

How To Create a Server Parameter File?
This is Step 5. The initialization parameter file is good to get an Oracle database instance started. But it is not ideal run an instance as production. You need to convert the initialization parameter file into a Server Parameter File (SPFile) using the CREATE SPFILE statement. The script below shows you how do this:
SQL> CREATE SPFILE=$ORACLE_HOME/dbs/SPFILEFYI.ora
2 FROM PFILE=$ORACLE_HOME/database/initFYI_ini.ora;
File created.
Note that $ORACLE_HOME should be replaced by the real path name where your Oracle server is intalled.
The SPFile should be located in the expected directory and named as SPFILE($SID).ora.
How To Start an Oracle Instance?
This is Step 6. Now you are ready to start the new Oracle Instance without any database. This instance will be used to create a database. Starting an instance without database can be done by using STARTUP NOMOUNT statement as shown below:
>.\bin\sqlplus /nolog

SQL> CONNECT / AS SYSDBA
Connected.

SQL> SHUTDOWN
ORACLE instance shut down.

SQL> STARTUP NOMOUNT
ORA-00821: Specified value of sga_target 16M is too small,
needs to be at least 20M
The SHUTDOWN command is need to bring the default instance XE down.
The STARTUP NOMOUNT command failed because it tried to start the default instance XE, and there is a bad parameter in the XE instance SPFile.
See the next FAQ question to find another way to start the new instance FYI.
How To Start a Specific Oracle Instance?
A simple way to start a specific Oracle instance is to start the instance with the PFILE option as shown in the following example:
>.\bin\sqlplus /nolog

SQL> CONNECT / AS SYSDBA
Connected.

SQL> STARTUP NOMOUNT
PFILE=$ORACLE_HOME/database/initFYI_ini.ora

ORA-02778: Name given for the log directory is invalid
The PFILE option allows you to specify the initialization parameter file of a specific Oracle instance. But the initialization parameter file created in Step 3 has some problem with the log directory.
How To Start Instance with a Minimal Initialization Parameter File?
The sample initialization parameter file provided by Oracle seems to be not working. But we can try to start the new instance with a minimal initialization parameter file (PFile). First you can create another PFile, $ORACLE_HOME/database/initFYI_ini_min.ora, as shown below:
db_name=FYI
control_files=("\oraclexe\oradata\FYI\control.dbf")
undo_management=AUTO
Then start the FYI instance again:
SQL> CONNECT / AS SYSDBA
Connected.

SQL> STARTUP NOMOUNT
PFILE=$ORACLE_HOME/database/initFYI_ini_min.ora

ORACLE instance started.

Total System Global Area 113246208 bytes
Fixed Size 1286028 bytes
Variable Size 58720372 bytes
Database Buffers 50331648 bytes
Redo Buffers 2908160 bytes
(Continued on next part...)
How To Run CREATE DATABASE Statement?
This is Step 7. Oracle Administrator Guide provided a sample CREATE DATABASE statement. But it is a long statement. You can modify and same it in a file, $ORACLE_HOME/configscripts/create_database_fyi.sql, and run the file within SQL*Plus. Here is a copy of the modified CREATE DATABASE statement:
CREATE DATABASE FYI
USER SYS IDENTIFIED BY fyicenter
USER SYSTEM IDENTIFIED BY fyicenter
LOGFILE GROUP 1 ('/oraclexe/oradata/FYI/redo01.log') SIZE 10M,
GROUP 2 ('/oraclexe/oradata/FYI/redo02.log') SIZE 10M,
GROUP 3 ('/oraclexe/oradata/FYI/redo03.log') SIZE 10M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE '/oraclexe/oradata/FYI/system01.dbf' SIZE 32M REUSE
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/oraclexe/oradata/FYI/sysaux01.dbf' SIZE 32M REUSE
DEFAULT TABLESPACE tbs_1
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/oraclexe/oradata/FYI/temp01.dbf'SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE '/oraclexe/oradata/FYI/undotbs01.dbf'
SIZE 20M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
Here is how to run this long CREATE DATABASE statement:
SQL> @$ORACLE_HOME\config\scripts\create_database_fyi.sql;
CREATE DATABASE FYI
*
ERROR at line 1:
ORA-01501: CREATE DATABASE failed
ORA-00200: control file could not be created
ORA-00202: control file: 'C:\ORACLEXE\ORADATA\FYI\CONTROL.DBF'
ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
Don't worry about the error messages. They are caused by the missing directory for data files in file system.
How To Do Clean Up If CREATE DATABASE Failed?
To better organize data files, you should create a dedicated directory for each Oracle database. This can be done by using Windows file explorer to create the \oraclexe\oradata\fyi\ directory. Try the CREATE DATABASE statement again, when you have the directory ready.
If your CREATE DATABASE statement failed half way again, you may have to clean up the partial result of the CREATE DATABASE statement. Here is a list of suggestions for you:
• Run SHUTDOWN command to stop the partial started database instance.
• Remove all files in FYI directory: \oraclexe\oradata\fyi\
• Run STARTUP NOMOUNT PFILE command to start the empty instance again to be ready for CREATE DATABASE statement.
How To Run CREATE DATABASE Statement Again?
After cleaning up the results of a previously failed CREATE DATABASE statement, you can run the CREATE DATABASE statement again as shown below:
SQL> @$ORACLE_HOME\config\scripts\create_database_fyi.sql;
CREATE DATABASE FYI
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
Something went wrong again. This time it might related the limitation that Oracle 10g XE only supports one database instance. With the default instance called "XE" already defined, creating another database instance might be not allowed.
How To Create Additional Tablespaces for an New Database?
This is Step 8. Creating additional tablespaces can be done by using the CREATE TABLESPACE statement as shown in the following sample script:
SQL> CREATE TABLESPACE users
2 DATAFILE '/oraclexe/oradata/FYI/users01.dbf' SIZE 10M;

SQL> CREATE TABLESPACE indx
2 DATAFILE '/oraclexe/oradata/FYI/indx01.dbf' SIZE 10M;
How To Build Data Dictionary View an New Database?
This is Step 9. The Oracle Administrator Guide suggests to run two SQL scripts provided by Oracle as shown bellow:
SQL> @/u01/oracle/rdbms/admin/catalog.sql

SQL> @/u01/oracle/rdbms/admin/catproc.sql