Keyboard mapping
From: Missy Schaetzke Missy_Schaetzke@zd.com
Sent: Monday, May 24, 1999 2:07 PM
Subject: Keyboard Mapping
We are in the process of upgrading from 10.7 character mode to R11. All
of
the function keys have been re-mapped to something completely different
than our users are accustomed to. I'd like to make the transition as easy
as possible for them. Is it possible to change the keyboard mappings in
R11? If so, how do I go about doing it?
Regards,
Missy Schaetzke
Sr. Systems Analyst
Ziff-Davis Education
Date: Tue, 25 May 1999 22:34:09 +0100
From: "Jonathan Stuart" jdstuart@globalnet.co.uk
Subject: Re: Keyboard Mapping
Missy,
The file $ORACLE_HOME/forms45/resource/US/fmrweb.res defines the keyboard
shortcuts that are assigned to each Apps function. If you want to use the
10.7 keyboard mappings you can replace this file with the 10.7 version.
Oracle supply the 10.7 version on the Developer 2000 Server 1.6 and 1.6.1
CD. The file is called 'fmrpcweb.res' and is in /extras/webkeys. Copy this
file onto your server and rename it to fmrweb.res, having backed up the old
version first!
This will give you the pre-NCA GUI keyboard mapping but not character.
Having said that, after taking a look at the fmrweb.res file (it is a text
file) it looks as if you should be able to edit this file and set the
keyboard mapping to whatever you want. I haven't tried this but it should
work and looks straight forward.
I hope this helps.
Regards,
Jonathan.
Tab Key not working in 11.02 apps
From: Bill Keenan [SMTP:bkeenan@goodegg.com]
Sent: Wednesday, May 26, 1999 7:55 AM
Subject: Tab Key not working in 11.02 apps
Hi All,
I am working in the finanacial applications, version 11.02 NCA,
(specifically G/L at the moment) and have run into some forms where my
tab
key, which should bring me to the next field, does not work. I am
finding,
at least in G/L, that this probem only exists when I am trying to put in
report parameters when trying to run any General Ledger Standard report.
This also happens on the other apps as well.
The tab key, which brings me to the next field in any standard form (such
as
"Enter Journals") works fine.
Does anyone know why this would be happening?
Any help is greatly appreciated.
Bill
From: Jennifer Knice JKnice@cerbpyro.com
Date: Wednesday, May 26, 1999 9:38 AM
Subject: RE: Tab Key not working in 11.02 apps
Bill,
We had a similar problem where the tab key was not working in the forms
when
we were in key flexfields. This occurred after we had applied a minipack
(mega patch). Have you applied and technical patches or a minipack lately?
Jennifer Knice
Senior Consultant
Austin Solutions
769 Susquehanna Ave
Franklin Lakes, NJ 07417
(201) 891-1460 - Office
(973) 593-6544 - Client Site
Date: Wed, 26 May 1999 09:43:05 -0400
From: "Bill Keenan" bkeenan@goodegg.com
Subject: Re: Tab Key not working in 11.02 apps
We are in apps 11.02, the technical 11.03 minipack and an AR and OE 11.03
minipack have been installed. How did you resolve this problem.
Thanks again for your help.
Bill
Date: Wed, 26 May 1999 09:26:20 -0500
From: "Cochran, John" John.Cochran@photomask.com
Subject: RE: Tab Key not working in 11.02 apps
11.0.3 broke the tab key in key flexfields and other areas. Patch number
857097 is available as a fix. I assume your problem is that you applied the
11.0.3 technical minipack, which is where it actually broke (FND).
-John
John Cochran
Solutions Architect - Information Technology
DuPont Photomasks, Inc.
(512) 310-6384
Date: Wed, 26 May 1999 10:00:49 -0700 (PDT)
From: sean a seansd@yahoo.com
Subject: IMPORTANT: tab problem and certified versions
for everyoen with the tab problem:
Before applying that patch for the tab problem, verify
your apps and database versions are certified. Apps
11.0.3 is only certified for 8.05 or 8.1.5 NOT 8.04.
We ended up with the tab problem, after applying some
of the the 11.0.3 patches. Restoring the database and
appl_top from tape back to 11.0.2 did not remove the
problem. Unfortunately, since we're still on 8.04
there is little Oracle can do. I am currently
finishing building up a secondary box with a clean
install of 8.04/11.0.2 to temporarily hold our
production database until I can rebuild the main box
and then do testing of 8.05 with 11.0.3.
Unfortunately, the 11.0.3 patch 794429 made no mention
of requiring database 8.05 or above.
Sean Allin
Tri-Marine International
Date: Wed, 26 May 1999 15:18:45 -0500
From: "Cochran, John" John.Cochran@photomask.com
Cc: "'seansd@yahoo.com'" seansd@yahoo.com
Subject: RE: IMPORTANT: tab problem and certified versions
Where did you get that information?? Certify shows 8.0.4 as being
certified. I have been working with support on 11.0.3 with 8.0.4 and no one
in support has mentioned that it isnt certified, and when asked, they say it
is certified.
-John
Prod to Test using Hot backup
Date: Wed, 2 Jun 1999 13:32:22 -0400
From: Stephane_Bouchard@cambior.com
Subject: Prod to Test using Hot backup
Hi,
I want to make a copy of my Prod instance to create a Test instance
using a Hot backup done daily. I tried to follow the steps as a cold
backup, by recreating the instance using the SET DATABASE 'TEST' but it
needs to recreate to correct control files first. How can i recreate these
control files in this situation. My platform is Windows NT 4 and the
database version is 7.3.2.3.8.
Does someone have the required steps that i need to go through to get this
instance to work, or if someone have a link to a web page where it could
guide me, It would be very appreciated.
I can't bring the server down and neither the instance because we are in a
24 h /7 days production site and my only option is to use the hot backup
files.
Thank you.
Date: Wed, 2 Jun 1999 10:33:53 -0700 (PDT)
From: sean a seansd@yahoo.com
Subject: Re: Prod to Test using Hot backup
http://members.home.net/arivenes/aolcopy.htm
here's the link i used as a basis for creating and
copying new instances of apps. hope this helps.
Sean
Date: Wed, 02 Jun 1999 14:28:34 -0700
From: Andy Rivenes arivenes@llnl.gov
Subject: Re: Prod to Test using Hot backup
Since you referenced my copy procedures, thanks by the way, I'll elaborate.
What's currently there is for full or cold backups. I have updated the
procedures for online or hot backups, but haven't had the chance to update the
web site, that's www.appsdba.com if you're interested. Anyway, I will post
them here for anyone else that's interested, sorry if its a little long. Note this
is the text version of just the changed sections. Eventually I will add the
EBU and RMAN specifics also, but just haven't had the time.
Starts here
Overview
These guidelines are meant to provide the information necessary to create a
copy of an Oracle Applications database on another similar machine. By
similar we mean of the same platform and operating system. Typically this
would involve copying a production database and creating or refreshing a
development database on another machine or location. However, these
procedures can also be used for copying databases on the same machine. The
sections that deal with the database are generic to the Oracle Server and
can be used regardless of whether the database is used for Oracle
Applications or not. The Oracle Applications specific sections refer to the
System Administration tasks that should be performed after copying an
Oracle Applications database, and changes to custom scripts that are
provided with our installations and will already exist for a system that
has been installed by us. The steps necessary for refreshing the Oracle
Applications product files have also been added. This step is not necessary
if the database is being refreshed into an existing environment or the
Oracle Application's environment is the same as the source database.
Recently these procedures have been restructured to document the steps
necessary to make the database copy using either a full backup (this is the
method this paper originally documented) or an online backup.
Backup The Source Database
In order to copy the database to another location (e.g. as in a refresh of
production data into development) either a full backup or an online backup
must be taken of the source database. A full backup is defined as a
physical copy of the database files after a normal shutdown of the
database. An online backup is defined as a physical copy of all the
database datafiles while the database is open and operational. It should be
noted that there are specific procedures that should be followed when
taking an online backup (e.g. ALTER TABLESPACE ... BEGIN/END BACKUP). See
the Oracle documentation on backups and recovery for further details.
Additionally, an online backup will require the source database's archived
redo log files from the point of the first datafile backup through the last
datafile backup.
In addition to all database datafiles, the init.ora and an ASCII copy of
the control file for the source database will be needed. The actual control
files are not needed as the ASCII copy will be used to create a new control
file to be used with the new database, and the online redo log files are
not needed as the new database will be created with the RESETLOGS command.
File permissions and ownership should be noted and this should be accounted
for when performing the backup and restore.
The following commands will create the ASCII control file (these commands
should be issued from the source database):
svrmgrl
SVRMGR connect internal
SVRMGR alter database backup controlfile to trace;
SVRMGR exit
This will create a trace file in the user dump directory of the source
database on the database server. This file can now be edited in order to
create the SQL script that will be necessary in later steps. The
appropriate changes needed are detailed in the section "Create Control File
Script" section.
Create The Target UNIX Environment
All database file directories will need to be created in the target
environment. It should be noted that these directories do not need to be
named the same as the source database's directories. The $ORACLE_BASE/admin
directory, and its sub-directories, for the new database should also be
created to provide a destination for the dump and configuration directories
(see OFA standards).
Restore The Source Files To The Target Machine
Once the source database backup has been completed the files backed up can
be restored into the desired directories on the target machine. File
ownership and permissions should be verified after the restore. If there
was an existing database that will be overwritten, this database should be
shutdown and backed up first. Don't forget to shut down the concurrent
manager processes also. Once backed up, the datafiles, control files, and
online redo log files associated with the database to be refreshed can be
deleted. All trace files can also be removed and if there are archive log
files they should be backed up to tape and deleted.
Create Control File Script
After the source database's datafiles have been restored to their target
directories, or these directories are known, the ASCII control file that
was created can be modified. The following changes will need to be made:
1. Remove all comments from the file (the Version 7.1 Server Manager
product does not support comments).
2. Rename the online redo log files and data files' directories to their
new names.
3. Replace the option REUSE DATABASE dbname with SET DATABASE
new_dbname where dbname is the source database name and
new_dbname is the new target database name.
Note: We now recommend removing the REUSE option to avoid errors when
increasing the size of the controlfile.
4. Replace NORESETLOGS with RESETLOGS. Required when the SET DATABASE
command is used.
5. Verify that the ARCHIVELOG or NOARCHIVELOG option is appropriate for
the target database.
Note: ARCHIVELOG will be required if an online backup was made.
6. Remove all further comments and commands. This includes the RECOVER
DATABASE command and the ALTER DATABASE OPEN command at the bottom of
the file.
7. Save this file as a SQL script with a name like new_control.sql. It is
probably easiest to locate this file in the $ORACLE_HOME/dbs directory
of the target database.
Modify The init.ora
At this point either the old target database init.ora file or the init.ora
file that was saved from the source database can be used, depending on
desired parameter settings and the changes necessary. In either case the
following items need to be verified/changed:
1. Change/verify all directory names.
2. Change/verify the "db_name =" parameter.
3. Change/verify mts parameters.
Rename The Target Database
We are now ready to start the database and rename it to the target name.
1. Create the new control file and rename the database:
Verify that the $PATH, $ORACLE_HOME, and $ORACLE_SID environment
variables are correctly set.
cd $ORACLE_HOME/dbs
svrmgrl
SVRMGR connect internal
SVRMGR @new_control.sql
2. At this point the instance is running and has the source name. The
next step varies depending on whether a full backup or an online
backup was performed.
Full Backup:
1. SVRMGR ALTER DATABASE OPEN RESETLOGS;
Online Backup:
1. SVRMGR RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
This command will result in the database prompting for archive
redo log files. The archived redo log files that were created
during the online backup should be applied and then the command
CANCEL should be issued to terminate recovery. The following is a
short example:
SVRMGR recover database using backup controlfile until cancel;
ORA-00279: Change 7239 generated at 05/21/99 10:26:19 needed for
thread 1
ORA-00289: Suggestion : /oracle/admin/copy7/arch/arch_9
ORA-00280: Change 7239 for thread 1 is in sequence #9
Specify log: {RET=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: Change 7244 generated at 05/21/99 10:39:07 needed for
thread 1
ORA-00289: Suggestion : /oracle/admin/copy7/arch/arch_10
ORA-00280: Change 7244 for thread 1 is in sequence #10
Specify log: {RET=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SVRMGR
2. SVRMGR ALTER DATABASE OPEN RESETLOGS;
1. At this point the database is now open and running. The database
global name should be changed (ALTER DATABASE RENAME GLOBAL_NAME TO
dbname.domain_name;) and all database links should be checked for
appropriateness.
2. Perform a full or online backup of the newly restored/renamed
database.
Runaway FNDLIBR Processes
Michael Porter wrote:
Has anyone run across finding several runaway FNDLIBR processes that
seem to not go away unless killed, even after a system reboot they reappear
the next day and have to again be killed???
UNIX AIX 4.2.1, Oracle 7.3.4.3, Apps 10.7/16.1
TIA,
Mike
Date: Fri, 04 Jun 1999 08:09:19 -0500
From: Dan Olson dolson@dacotah.com
Subject: Re: DBA: Runnaway FNDLIBR Processes
Typically this will happen if the a shutdown immediate is run with the
concurrent managers still running. This happens to me when the CRON for
cold backups runs a shutdown immediate before the shutdown of the CMs.
What I did was write a seperate script that is called for each instance
(concshut.instance name) and include it in the backup script.
The shutdown CM includes for each instance something like:
mount pt/appl/r10/fnd/6.1.1/bin/CONCSUB apps/apps password SYSADMIN
'System Administrator' SYSADMIN WAIT=Y CONCURRENT FND DEACTIVATE
hope this helps
Dan Olson
SPF Energy Inc.
Date: Fri, 04 Jun 1999 08:52:07 -0700
From: Daniel Booth dabooth@us.oracle.com
Subject: Re: DBA: Runaway FNDLIBR Processes
FYI
You must shutdown the concurrent managers BEFORE shutting down the database to
avoid run away FNDLIBR processes. To do this you should use ABORT not
DEACTIVATE command in the concsub command that Dan Olson described. If you use
WAIT=Y and DEACTIVATE then you will not shut down the concurrent manager until
all jobs that are running stop. This can be minutes or hours. If you use ABORT
then all running concurrent process are terminated then the concurrent managers
stop.
Needless to say use the abort command only when you MUST shutdown the database
immediately. You may cause some problems with running processes if you abort
them.
Daniel A. Booth DBA
Principal Consultant Oracle Financial Applications
Telecommunications
1000 SW Broadway, Suite 1200
Portland, Or 97205
Voice Mail 800 862-4563 mailbox 2204
E-Mail dabooth@us.oracle.com
Client Phone: 425-580-7711
Date: Fri, 04 Jun 1999 13:08:19 -0500
From: Dan Olson dolson@dacotah.com
Subject: Re: DBA: Runaway FNDLIBR Processes
Daniel Booth makes a very good point - Use ABORT for shutting the CMs
in hurry. DEACTIVATE will take several (I think 5) minutes even if
nothing is running. I was talking about cold backup shutdown as a
possible cause for the run away FNDLIBR processes. For us, aborting a
night time report to do cold backups every night would not go over real
well. If you are getting a run away in a consistent fashion, I would
check all CRONs and scripts for shutdowns.
It is interesting to me that a shutdown immediate or shutdown abort does
not ALWAYS cause the run away. For example - my co worker ran the old
dbshut.i (immediate) script when we had 5 instances and 5 concurrent
managers running, only one instance had a FND run away. Perhaps someone
can explain the inner workings? - but I suspect it may fill a book.
Dan Olson
SPF Energy