May 1996 Newsletter

CSA provides a cost effective and efficient alternative to your company's System Administration (SA) and Database Administration (DBA) support structures. By providing expert staff and state of the art monitoring software, CSA can improve your Unix system and Oracle database performance and availability while reducing the overall cost of these services. CSA can work as a complement to in-house staff or totally outsource your SA/DBA support activity. Bring us in for an initial consultation and find out what a difference CSA can make. Contact us using e-mail at admin@csac.com or call 214-960-0180 or 1-800-225-6204.

The March meeting of the Dallas Oracle Users Group was held at Oracle Corporation on Thursday, March 21 1996.

The first order of business was to again ask each member to confirm that DOUG records accurately reflect current address information. If you are a member, but haven't been receiving your bimonthly newsletter, then we don't have your correct address. Please contact Mark Shelton with your updated information at metro (817)530-5495. You can also leave a message at the DOUG hotline 214-606-5222.

The first presentation given by Michael Coleman of Oracle Corporation was an overview of the new features offered within Oracle 7.3 . This informafive presentation outlined the options available with the Universal Server, of which the RDBMS v7.3 is a component. Audit and video support as well as support for special data are only a few of the new features that were discussed.

Other improvements we can all look forward to within Oracle 7.3 include dramatic performance improvements, bit-mapped indexing, unlimited extents, free space coalescing and new performance management tools. Michael provided the group with informational handouts that offered more detailed information.

The second presentation was given by Mr. CSA himself, John Stouffer. This discussion was focused on Release 10 Applications upgrades and was extremely helpful in giving us all some insight into preliminary steps that should be accomplished prior to doing the upgrade. John discussed the importance Oracle is putting on certifications of product combinations and we learned that all of our databases must now be OFA compliant. Other significant information was presented as well as several "war stories." John provided the group with a handout outlining the upgrade tasks and providing other valuable information.

Check the DOUG web site (http://www.doug.org) for more information about the Applications certifications. We'll be posting them as we receive the information.An announcement was made about the Oracle Development Tools User Group (ODTUG, formally OCSIG) conference to be held in San Diego May 15-18. This intemational Oracle user group focuses on Designer/2000, Developer/2000, Discover/2000, Data Warehousing and development methodologies. For more information call (910) 452-7444 or check out the web at www.ocsig.com.

Refreshments were provided by David Behringer, compliments of the Maxim Group. Thank you David - the cookies and drinks were great.

The next DOUG meeting will be an Applications Special Interest Group gathering on Thursday, April 18, 4pm to 6pm at Oracle Corporation.

-M.Conroy, VP

Minutes from the April DOUG Meeting

The April meeting of the Dallas Oracle User Group Applications S.I.G. was held at the Oracle Corporation offices on Thursday, April 18, 1996. The informal opening of the meeting was conducted by Barbara Marcum. Refreshments for the meeting were generously provided by Computer Systems Authority.

The guest speaker was Don Warren of Oracle Corporation. Don conducted an overview of the new Oracle smart client product. Don provided live demonstrations of the General Ledger, Accounts Payable and Order Entry smart client on version 10.6. The current release dates for this production version 10.6 are:

     General Ledger                               available now
     Accounts Payable                             available now
     Order of Shipping/Order Management           available in June
     Receivables                                  available end of April
     Purchasing                                   available end of May
     Project Accounting                           available end of May on 10.6.4

Don continued his presentation with a short demonstration of a new use of the Web for retrieving purchase requisitions.

At the close of the meeting, Lisa Thrower announced the new on-line OraJobs service which is now available on-line. The DOUG group has agreed to the creation of the OraJobs-L@list server at the doug.org domain. This list server provides a forum in which employers can search for the right Oracle resource, and people with Oracle related experience can find the position that is right for them. [Editor's Note: See the related article on page 11.]

The next DOUG-Applications S.I.G meeting will be held on June 20, 1996 and the topic will be Oracle matching. An overview of the AP/Purchasing/ Receiving matching will be conducted and a pros and cons of automated matching will be provided by end users.

Techniques For Fast Database Re-Organization

Summary

This paper will discuss a number of features and techniques available within the Oracle RDBMS which can dramatically speed the reorganization of databases. However, well tuned the storage parameters within a database, there will eventually come the time when you need to reorganize all, or part of the database. This could be to reduce fragmentation, general house-keeping, or when moving to a new operating system. The current utilities which came with Oracle were never designed to move large volumes of data in a short period of time. We recently moved our 60 gigabyte production database to a new machine. If we had used the standard export/import' method we estimated the whole move would have taken at least 12 days, but using the techniques we developed, the move was done in 18 HOURS. As the database grows and as business considerations limit maintenance time, fast database maintenance is essential.

Overview of Churchill Insurance

Churchill Insurance has a single database of over 60 gigabytes of data and runs a 6 by 24 hour operation. Churchill uses a Cray Superserver 6400 as the database server with 600 high OLTP concurrent users, having recently moved the database from a Pyramid Nile.

The main production database is running under Oracle 7.1 and generates approximately 4 gigabytes of archived redo logs a day. During peak we parse 250 new SQL statements per second and execute 350 SQL statements per second. The database grows by 15 gigabytes per year.

Exporting Data

On UNIX, Oracle links the EXP/IMP programmes in two task mode. This is so that the SGA can be protected from potential corruption by users own programmes. It is possible to relink the EXPort programme in single task mode and gain as much as 30% improvement. This can only be run from the 'Oracle' account. Remember, Oracle does not support this usage in UNIX (I hear they do use it themselves).

A FULL database export will not make good usage of the machines resources. If your machine has a number of CPU's available, exporting the database will only use one. You need to ask yourself 'How many CPUS, Disks, Networks etc. do I have?' and then think about how to make maximum use of them. Most UNIX systems have a maximum file size limit of 2 gigabytes so you might have to export to tape or raw device.

For example, if your machine has 10 CPU's with lots of free memory and you wish to 'exp/imp' a database; if you use EXP to do a FULL database export you will only have one process writing the whole export to a single file. Your remaining 9 CPU's are idle. A much more efficient way to fire off multiple single table export in parallel. We developed a programme to schedule this automatically but some editing of script files could achieve the same effect. You should sequence the biggest jobs first because in theory, if you get the correct number of streams and have a large machine, your total export should only take as long as your biggest single table (i.e., you have exported all other tables by the time the biggest completes).

You could do a full database export without the data to get just the database structure in a export file. Because I/0 can become a major bottle neck in the performance, you could also split the export/output files to different disks.

Importing Data

Now you have your export files, what can be done to speed up your imports? Firstly, you can do the same as the exports and run multiple streams of import with their I/0 split. If you wish to keep archive log enabled, remember to manage the space of archive logs generated. Of course, you can link the imp programme in single task mode and see improvements of 30 percent. Since you are now exporting single tables you can start to import the completed export files while other tables are still exporting. If you were copying the data to another machine you could copy the completed files across while waiting for other exports to complete. Now you are importing a large volume of data quickly, you will find that Oracle is able to fill the database very fast. Ensure you have a number of large redo logs during the import which you can drop once the build is complete. There are two reasons for doing this. Firstly, if you don't do this you will find all your on-line redo logs fill very quickly and the database will become very slow (watch for 'Thread x cannot allocate new log... Checkpoint not complete' in the alert log). Secondly, each time Oracle fills an on-line redo log (or reaches LOG - CHECKPOINT-INTERVAL) a Checkpoint occurs. Checkpoints can hinder performance because dirty data blocks in the SGA are written back to disk. For a very large SGA this can take minutes. At Churchill we always set LOG-CHECKPOINT-INTERVAL to a larger than any redo log and this causes checkpointing to only occur when switching redo logs. Checkpoints work on a queuing system and you can find that the next switch of redo log will cause another checkpoint before the previous one is complete. It is possible to still fill all the redo logs even if they are large. If we were importing a 1 gigabyte table, we would create two 500 MG redo logs and the import would only checkpoint twice.

We have found we can make import twice as fast by saying 'COMMIT=NO' during an import. Although 'COMMIT=NO' is the default, most DBAs set 'COMMIT=YES' so that during large imports a small number of rows are committed at a time so that the rollback segments are not exceeded. Since import can be 50% faster if the complete import is done in one transaction, it would be very useful if it were possible to know how much rollback segment the import would use before you start. Using 'COMMIT=N, each table import is seen by Oracle as one transaction, you must allow enough space in the rollback segment. I never could understand why, if I used IMP to import a large table I would blow my rollback segment. I would then have to say COMMIT=y for the import to work and commit each row at a time.

'How could I generate rollback segment entries on an insert when I would have no old data to rollback?'. Oracle must know which rows in the database to rollback. The space required in the rollback segment is far less than that of the table to be created. It's based on the number of rows per block and the number of blocks used to store the data in the new table. The information held in the RBS is basically a pointer to each block and a 2 byte pointer to each row in the block. There is also an 84 byte header to each RBS block. Each block in the new table has a 58 byte header to the RBS.

To Calculate the Required Rollback Segment
(Insert of data only!)

Firstly, work out the average number of rows per block. You can either calculate this or use ANALYSE. To calculate:

Now calculate the size of the required rollback segment in two stages

I suggest that you allow for the biggest table and then set a number of rollback segments which all can grow to this size. The above formula was used to calculate a 3 gigabyte rebuild to the nearest 1 megabyte (only 131 megabytes).

Copying Data (any version of Oracle)

There is a better approach to rebuilding tables within the same database which is more than twice as fast as export/import and produces no flat files. We wrote a PL/SQL package to automatically manage the streaming but this document will only explain the basics of the data process. You are able to move very large volumes of data around the same database (table space to table space) using 'CREATE TABLE SELECT*FROM'. Constraints make it a little more complex. We have used this to move gigabytes of data within the same database and seen very fast times. We have also tested using this method between two databases, but we found the SQL*NET became a major problem and the speed was far too slow for large volumes of data. This technique also gets around the UNIX 2 gigabyte export file size limit since no files are generated. You should also note that like importing with 'commit=N' this is done as a single transaction and you should calculate the rollback segment requirements. This paper will later talk about a number of changes with this in Oracle 7.2.

If you are using constraints be careful of the 'NOT NULL'. If you say:

Oracle will create and copy the data in the table OK BUT, Oracle will then scan the whole table checking the NOT NULL constraint. This is an extra task which you don't want (also with the BLOCK CLEAN OUT delays). If you do this:

Oracle will also build a CHECK constraint but the testingis done as the rows are inserted and no checks are made after the transfer is complete. In one example I copied a 3 gigabyte table in 4.5 hours using NOT NULL (and the CHECK constraint generated by Oracle). The same build took over 9 hours with the statement which only had the CHECK constraint.

What can be done to speed up the index builds? Again you can run multiple index builds but note that you may not be able to run a high number of streams. To avoid sorting the index on disk increase the SORT-AREA-SIZE in the init.ora. If you have a 200 Megabyte index to build and enough memory on the machine you can set the sort_area _size 200 MG. Sorts done in memory can save hours on an index build. If you can't sort the whole index in memory then set the sort_area _size as large as you can but you will need a large temporary table space to sort in. Remember to change the SORT_AREA_ SIZE back to the original value once the builds are complete.

Oracle 7.1 introduced a number of new parallel functions and index building was one of them. You can now split a single index build into a number of streams. How many streams should you use? We did some tests and found that with our configuration the best number of streams was 4 or 5. After that number we started to bottle out on I/0 and as we increased the work load we got very little speed improvements. We used a 370 megabyte table and found that we could reduce the index build to under half using 4 streams. We felt that 4 streams should give a quarter of the speed. The problem was that as more streams were loaded the I/O became the bottle neck. By using operating system disk striping we were able to spread the I/0 over a number of devices. The original 1 hour index build could now be done in under 10 minutes. We tested with different numbers of disk in the stripe and we now standardize on 4 disk stripes. Performance stops improve after about 4 to 5 parallel processes. Since an 8 disk stripes far harder to manage and less secure we now use 4 disk stripes. However, you should know that if one disk in a stripe fails, all database files on the whole stripe will go off-line.

During our recent migration we developed a pl/sql programme to automate our index builds in parallel. Because we wanted to build all our indexes in memory and we had 12 gigabytes of indexes to build and only 4 gigabytes of machine memory, we put in an addition to our programme to limit the number of streams so that they never used more than 3 gigabtyes of memory. It's also important to remember that each parallel stream will have two parallel server processes. Therefore a 4 stream index build will have 8 processes and thus will use twice as much sort-area-size. Another change we had to make which goes against normal parallel processing was to sequence the index builds so the smallest indexes was build first and the largest was build last. This was necessary because the parallel processes do not release their memory once a index build completes. Example:

First index may require 800 megabytes, second only 300 megabytes. This is now wasting 500 megabytes during the second build. If you now do this for 30 streams you will start to see 'malloc' errors from Oracle. By creating small to large, each process only ever grows to its memory requirement.

Data Transfer Using Named Pipes

When we were trying to find a way to move our 60 gigabyte database we were left with a major problem. We had 30 gigabytes of raw data to move and this meant we would need an extra 30 gigabytes of disk on each machine to export to and import from. The 'CREATE TABLE SELECT*FROM' method of moving data within the same database is very efficient but what about moving data from one database to another? We tried the create table method over SQL* net and found very poor performance (waiting days in some cases!). In the past we successfully moved a 20 gigabyte database by exporting to flat files, copying the data across the network and then importing the data. The whole process was done in parallel and at the time we felt this was the fastest solution, but was it?

The solution we came up with to move data between two machines was much faster than export/import and produced no files. The idea is based on using 'named pipes' on UNIX. We saw amazing results. A names pipe is a UNIX feature which allows a pipe to be defined which looks like a file. Another process can read from the pipe until there is nothing to read. Using this method we are able to define a pipe file, then define another pipe on the other machine and start IMPort running on that machine. At this stage both processes will hang ('EXPort', because nothing is reading from the pipe, and 'IMPort' because nothing is writing to the pipe). The final step is to fire off a UNIX file copy from the first file to the second file. The table will now be exporting and importing at the same time. As well as good performance, no extra disk areas are needed for the export file. Of course, you can then start to use multiple streams during the processes. During our production move we were able to move 30 gigabytes of data in under 6 hours.

Our normal way to copy data would be 'Exp/rep/imp (Export to file. Remote copy the file to another machine. Import that flat file.). As you can see, the normal method would take 32 minutes compared to 20 minutes for the pipe method. That gives an improvement of 30 percent. If you also set COMMIT=N with the same parameters you will see a 50 percent improvement. You should also note that the default buffer for our machine is 30K and we see poor results with that value. Overall we have been able to improve from 32 minutes down to 10 minutes (a savings of 70 percent!!!!).

Creating Tablespaces (Oracle 7.x)

An obvious way to speed the creation of tablespaces within a database would be to run them in parallel. Unfortunately a 'feature' of the internal locking within Oracle results in only ONE table space being added to the database at one time, each process will wait until its turn.

The trick you can use to achieve parallel table space creation and bypass the Oracle locking problem is to create all your table spaces in a single stream of size IOK bytes, then drop all the tables spaces. Now create them the correct size in parallel BUT IN THE REVERSE ORDER to the original create statements. We developed a programme which automatically does this but it's possible to do it by hand. The order is very important, so if you get any sequence incorrect the build starts to lock up again. We have been able to generate a 60 gigabyte database shell starting from nothing in under one hour using this technique. On the same system we expect it to take well over 15 hours in a single stream. Another thing we did to achieve such good times was to sequence the build so that the I/O was spread evenly over all available disks and disk controllers.

Overview of Our Pyramid to Cray Move

• 6OGB parallel database creation - (1 hour);
• Multiple export/imports in single task;
• Export/import 30 GB using pipes - (6 hours);
• Split over 4 back bone networks;
• Index built in memory parallel - (12 hours);
• Programme to monitor data load and predicts completion time for any tables;
• With automatic error checking;
• Check number rows in both DB's

Oracle 7.2

The 'CREATE TABLE SELECT*FROM' has been extended on version 7.2 to use the direct load path options (as in SQL*Loader) to copy tables within the same database. The speed improvements are dramatically faster than before because the data bypasses the internal SQL layer. If you specify the PARALLEL option in the CREATE statement Oracle will read and write the data in parallel. When I wrote about the streaming of EXPort I stated that your export could take as long as your largest single table. Now we have a way of evening streaming a single table build. Another major improvement is because the data is loaded using the direct loader - no rollback segment data is generated and no blocks are marked dirty. This means index builds on tables built this way be much faster (clean out alone added 5 hours to our recent migration).

Another feature of 7.2 is the ability to build tables and indexes with the 'unrecoverable' option. There are two major benefits of this option. Times for building objects are faster because Oracle no longer has to write the new data into the redo logs. When a block is written to a redo log block, Oracle must wait for confirmation that the data got there. The second benefit is if you are running your database in Archive log mode, all others transactions are still Logged. The disadvantage of this option is that once your build is complete, you have NO ability to recover the table if the table space needs recovery.

Once the build is complete you MUST get a backup of your database. If the backup falls, you can't recover your database from an earlier backup and roll through the logs (Churchhill NEVER switch off archive log and therefore can roll forward from any backup taken months earlier). There has been an undocumented/unsupported way of turning off redo logging at database level from Oracle 7.0 but since there was no way to recover after a crash it was not worth the performance increase.

Using 'unrecoverable 7 we have seen improvements of between 10 and 40 percent. The key to the improvement is whether your redo logs are on their own disk. If they are we only see 10 percent improvement using 'unrecoverable'. The 'unrecoverable' option does have a use for duplicating temporary data and new database builds but I feel its use would be limited on production databases.

The times for copying a 2 GB table. As you can see, it was possible to copy a full 2 gigabyte table in fifteen minutes.

	Version	  Streams    Unrecoverable 	Time
	7.1	  1	     n/a	        3:00
	7.2	  1	     recoverable	2:20
  	7.2	  1	     Unrecoverable	2:05
	7.2	  5	     recoverable	0:33
	7.2	  5	     Unrecoverable	0:21
	7.2	  8	     Unrecoverable	0:15

Conclusions

As a DBA you will need to consider which techniques to make use of depending on available resources. You should also evaluate some of the risks involved. All of these techniques will speed up your re-organizations but they need more planning, performance/task monitoring and good decision making if errors occur. Good system administration skills may be needed in monitoring the machines resources. Notes should be taken of any changes made during the build work so parameters can be set to their original values once complete. Other considerations can be that your recovery may be slower if you hit certain problems. For example, you can speed your import with 'COMMIT =N' but if your import fails you must wait as long as your import had taken, for the rollback to complete. Large redo logs will reduce the delays of check pointing but could increase recovery time after a crash. If careful planning is done and with adequate disaster recovery you should be able to dramatically improve your Oracle database reorganization.

This article was previously published in the EOUG Magazine and was re-printed with the author's permission.

Vari-Lite, Inc. is a rapidly growing, international company in the automated lighting industry that provides service in the live entertainment markets of theatre, television and concert productions. We offer competitive salaries with a team-oriented work environment. Vari-Lite will reward your commitment and performance with a comprehensive benefits package including medical, dental, vision, life insurance, and retirement incentives. Requirements for the positions are as follows:

Oracle Manufacturing Analyst/Programmer

BS or MS in Computer Systems with a minimum of 3 years manufacturing experience with knowledge of SQL, C/C++ is required, preference given to Oracle FORMS and REPORTS in an Oracle manufacturing application environment. Responsibilities will include analysis, design, construction and testing of software programs. This position requires excellent end-user communication skills, along with demonstrated software design and development skills.

Oracle Database Administrator/Modeler

BS or MS in Computer Systems with a minimum of 3 to 4 years of demonstrated database administration experience is required. Responsibilities include designing and integrating new applications in the existing Oracle system. Familiarity with Sun Solaris 2.x is preferred. The successful candidate will have experience with database construction and maintenance, excellent communication skills, and the ability to handle multiple projects in a fast-paced, technologically expanding manufacturing environment.

Please forward your resume and salary requirement to: Vari-Lite, Inc., Attn: Human Resources Department, Ref.#DO50196, 201 Regal Row, Dallas, Texas 75247 or fax to (214)630-5867. No third party inquiries accepted. Vari-Lite,, Inc. is an Equal Employment Opportunity Employer.

Legacy Consulting, Inc. has IMMEDIATE OPPORTUNITIES in Dallas, Texas and surrounding areas.

FULL-TIME PERMANENT positions for Oracle Instructors and Oracle Consultants in these areas. Oracle DBA'S, Financials, Manufacturing/Order Entry, Oracle Express, Java, PL/SQL, and Designer/Developer 2000.

Legacy Consulting, Inc. offers an excellent compensation package and a chance for financial and career growth. Our Corporate office offers Free Training for our Permanent Consultants.

Legacy Consulting also offers permanent placements. If you do not want a Contracting position, but would like to work for a major corporation, let us find your new job for you through our placement services!!!

For IMMEDIATE consideration fax or mail resumes to:

Fax: 214-361-7628 Voice: 214-361-6730 or visit us on the web http://www.legacyinc.com

Greetings Everyone!

It is my pleasure to announce the creation of the OraJobs-L (copyright) list server hosted by DOUG, the Dallas Oracle Users Group. Members of DOUG Board of Directors have approved the creation of the OraJobs-L (copyright) list server at the doug.org domain. This list server provides a forum in which employers can search for the right Oracle resource, and people with Oracle related experience (Applications, Tools, RDBMS, etc ... ) can find the position that is right for them. It will also provide a way of reducing employment-related traffic on the technical and applications oriented lists, leaving them for their intended purposes.

ORAJobs-L(copyright) is a non-biased, unmoderated list service to which anyone can subscribe. It is based on the Major Domo list server and runs on the Sun workstation that hosts the doug.org domain. There will also an FTP site on the server available for the exchange of employment related documents, etc., so stay tuned! Below are instructions on how to subscribe to service, and the rules regarding its use.

For now, the list server will send whatever is posted to the list. It has a digest mode to allow the subscriber to receive only one (hopefully) large mail per day. In the future, the list server will receive feeds from Major Oracle related UseNet sources.

I am grateful to the DOUG board for allowing this facility to reside on the doug.org domain, and believe that it will be a significant communication vehicle for employers and those seeking employment for some time to come.

To subscribe, send an e-mail with no subject to MajorDomo@doug.org with the following text in the body:

where e-mail is your electronic mail user and host is the host name or domain of your mail provider.

Please send inquiries to: OraJobs-L-owner@doug.org.

Regards,

Peter Hand
Computer Systems Authority
D.O.U.G. Member

Instructions for OraJobs-L:

This is Brent Chapman's "Majordomo" mailing list manager version 1.93. In the description below, items contained in [] are optional. When providing the item, do not include the []'s around it. It understands the following commands:

subscribe <list> [<address>]       Subcribe yourself (or <address>
                                   if specified) to the named <list>

unsubscribe <list> [<address>]     Unsubscribe yourself (or <address>
				   if specified) from the named <list>

get <list> <filename>              Get a file related to <list>
 
index <fist>                       Return an index of files you can
				   "get" for <list>

which [<address>]                  Find out which lists you (or <address>  
			           if specified)  are on.

who <list>                         Find out who is on the named <list>

info <list>                        Retrieve the general introductory 
				   information  for the named <list>

lists                              Show the lists served by this 
			  	   Majordomo server.

Help                               Retrieve this message.


End                                Stop processing commands(useful if your 
		                   mailer adds signature

Commands should be sent in the body of an email message to "Majordomoc@doug.org".
Commands in the "Subject:" line are NOT processed.
If you have anny questions or problems, please contact "OraJobs-L-Owner@doug.org".

Regional and National User Group News

COMING SOON.... NoetixViews will be doing a presentation at Oracle Corporate Offices May 16 from 1:00 to 3:00 / Room 1004. (same day & loca- tion of May DOUG meeting.

Mark your calendars now! SCOUG will be holding a two-day conference this summer. Monday and Tuesday, June 3-4, Galveston will be the site of a regional conference that will include education, presentations, and vendor exhibits.

CASE SIG NEWS

About OCSIG/ODTUG

OCSIG/ODTUG is an international user group for information systems professionals who use Oracle Designer 2000, Developer/2000 and Discoverer/2000 to develop high quality, reliable systems. The membership consists of more than 1100 members from 3 8 countries. Member's interests cover all aspects of the system development life-cycle, including the business process design, analysis, modeling, design and development.

OCSIG/ODTUG's mission is to:

• Establish members as leaders in their organizations
• Provide timely access to the latest technology and information
• Influence Oracle's strategic direction
• Influence Oracle's technical direction

OCSIG/ODTUG provides numerous benefit to its members including:

Access to early pre-production and trial releases of new products
• Award winning quarterly newsletter, briefCASE
• Electronic mailing lists
• Web site, www.ocsig.com
• Discounts to semi-annual conference

For further information contact:
OCSIG/ODTUG
2840 South College Road, Suite 151
Wilmington, NC 28412
Phone: 910-452-7444/Fax: 910-452-7834
CompuServe: 102351-1311@compuserve.com
Web: www.ocsig.com

In December, Oracle's Applications Division formally announced the end of Customer Care Support for Oracle Applications Version 9. The latest release of Oracle Applications Version 9 is release 9.4.2. Customer Care Support for all Oracle Applications Version 9 releases running with Oracle RDBMS Version 6 will end on June 30, 1996. Customer Care Support for all Oracle Applications Version 9 releases running with the Oracle7 RDBMS will end on December 31, 1996. Supported Oracle Applications customers are entitled to latest release of Oracle Applications Release 10 at no charge.

Extended Assistance Support will be available for 3 years after Customer Care Support ends to those customers who are unable to migrate before Customer Care Support ends. Extended Assistance Support provides for telephone and electronic support only, consisting of the following:

• Answering customer questions
• Providing workarounds and fixes that may be available for known problems, if possible
• Providing customers with migration path information

Extended Assistance Support does not provide for the following:

• Software error correction support
• Backporting of fixes
• Certification with supported products or new operating system releases
• Escalation Support or guaranteed response times or skill availability.

Due to these limitations, Oracle strongly recommends that customers plan and upgrade to Oracle Applications Release 10 as soon as possible to maintain the highest level of support for their products and systems.

Dallas Oracle User Group Newsletter          Issues 26,May 1996