Oracle 10g Too Many INACTIVE Processes in V$SESSION

Help.
I have a 10g Catelogue database that I use only for RMAN backups for other databases, it
sits on a Windows 2003 server.
My problem is that it is generating a lot of INACTIVE processes for user SYSMAN to such an
extent I had to increase the processes to 600 from 150 (SQL> Alter System Set Processes=600
Scope=spfile;), but by the rate the INACTIVE processes are coming I get database connection
errors and memory errors after a few minutes/hrs after restarting the database.
SQL> select count(*), username, status, state
2 from v$session
3 group by username,status,state
4 /
COUNT() USERNAME STATUS STATE*
2 SYS ACTIVE WAITED SHORT TIME
15 ACTIVE WAITING
234 SYSMAN INACTIVE WAITING
SYSMAN has about 234 INACTIVE processes above, but that figures rises sharply. After some
moments (1 hour) when I try to run the select statement again I get:
SQL> /
from v$session
ERROR at line 2:
ORA-04030: out of process memory when trying to allocate 123404 bytes (QERGH
hash-agg,kllcqas:kllsltba)
When I exit SQLPLUS and try to login I get this
C:\>sqlplus
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Oct 8 12:55:14 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter user-name: / as sysdba
ERROR:
ORA-12560: TNS:protocol adapter error
Enter user-name:
So I have to restart the database.
Help me solve my problem.
Regards,
Kevin

These are the EVENTS and it seems they have the same count and also they constitute the majority
SELECT count(), event*
FROM v$session_event
WHERE SID in (Select SID From V$SESSION WHERE USERNAME = 'SYSMAN' AND Status = 'INACTIVE')
GROUP BY event
ORDER BY Event
COUNT() EVENT*
309 SQL*Net break/reset to client
309 SQL*Net message from client
309 SQL*Net message to client
309 control file sequential read
16 log file sync
The method of the RMAN backup:
I'm using windows scheduler to run RMAN scripts with a command like:
rman target / @livedb catalog / @catalogdb backup database;
Regards,
Kevin

Similar Messages

  • Too  many parallel processes

    Hi
    I will have to build process chain to cube 0SD_C03 and the datasources are
    2LIS_12_VCITM
    2LIS_12_VCHDR
    2LIS_12_V_ITM
    2LIS_12_VDHDR
    2LIS_12_VAITM
    2LIS_12_VDITM
    2LIS_12_VADHDR
    Now the question is after providing the links between " Delete index" process and individual  loading process (Infopackages),the message I am getting in the checking view is " Too many parallel processes for chosen server " and furthe,r the suggested procedure by system is " Reduce the number of parallel processes in the chain or include sub-chains :
    How can I reduce the processes? Is there any alterante method of building this flow to avoid warning messages..
    Though these are warning messages ,what is the correct flow of building process chain for this without getting any warning messages.

    Hi,
    Based on dependency better you can go for 3 parellel process at a time as what we are doing in our project. 
    check schedule time for each your process chain which fetchs data from source system (Info Package) and re schedule them which should not execute at a time (make it max 3) and try again
    Regards
    BVR

  • Too many java processes.

    Hi,
    I have installed Forms & Reports Services Standalone 10.1.2.0.2 on RHEL 5 and applied the 10.1.2.3 patch to it. After the patch, the java processes continue to grow so fast that sometimes when I open a new session and try to switch to oracle user, I get a "too many processes" error.
    Apparently these java processes are from the Reports Server, however I haven't even yet configured the Reports server and am not doing anything with the reports server at the moment. Right now, I'm only configuring the Forms server.
    So, I am wondering what is going on here - why are there so many java processes and what to do about it?
    Thanks.

    Hi,
    Based on dependency better you can go for 3 parellel process at a time as what we are doing in our project. 
    check schedule time for each your process chain which fetchs data from source system (Info Package) and re schedule them which should not execute at a time (make it max 3) and try again
    Regards
    BVR

  • Why are there so many inactive processes running on my computer?, etc.

    Hi,
    This issue might already be addressed but my MacBook Pro has been really slow lately and when I checked the activity monitor, the inactive processes take up half of the system memory. Usually, how much space is this supposed to take? I only have the basics plus Sophos running. I've been trying to check to see what's running but sometimes some disappear and appear momentarily. In general, what's the idea or normal composition of system memory? Any help would be much appreciated.
    Usually, this affects Safari which is slow when I switch between tabs, etc. Now, the browser has been quitting more frequently with the Java 10.4-.5 message appearing. What should I do to remedy that problem?
    Many thanks for any input!

    It is normal for there to be quite a number of inactive processes.
    the inactive processes take up half of the system memory
    There is some confusion in what you are asking. Are you talking about inactive memory? Inactive processes will not be using any CPU, but they may have inactive memory allotted to them. This is memory that, should another process require it, can be reallocated to that other process. It's like a kind of caching: it can quickly be drawn upon should the inactive process become active again and need it. In the meantime, it is free for any process to use. It is not being wasted or used.
    Usually, how much space is this supposed to take?
    You are introducing the word "space" here. I'm not sure what you mean by that, but I don't think it's applicable.
    I've been trying to check to see what's running but sometimes some disappear and appear momentarily.
    That is normal for Activity Monitor. I think you need to have a better understanding of Activity Monitor.
    http://oreilly.com/pub/a/mac/2005/10/04/activity-monitor.html
    Sophos may be slowing down your computer. You should turn off its always-on scanning feature (or whatever it's called) and just run it on demand.

  • Too many inactive database connections (c#, webapp, Oracle)

    <br /><p> </p><p>I have a web application that uses the CrystalDecisions.Web.CrystalReportViewer to display my reports. </p><p>The application opens a connection to an Oracle database with SetDatabaseLogon(). </p><p>I have not yet implemented anything to free the connections when they&#39;re not needed anymore. I read in the  </p><p> Crystal help that the best place to call ReportDocument.Close() is in the Page_Unload method.</p><p>The problem is that my reports have dynamic cascading  parameters that make the page reload (ie Page_Unload -> Page_Load) several times. </p><p> </p><p>I can eventually call  ReportDocument.Close() in a Global.asax method, like Session_End(), but I&#39;m not sure it is optimal, as my report object is not known in this scope and I have extra code to write to handle this.</p><p> </p><p>Is there a better way to manage database connection ? </p><p>Can anyone provide a working sample ?</p><p>thanks </p>

    <p>I&#39;m not aware of a better way.  Your connections are definately being held up because you are not closing the Report.  Possibly you could put a conditional ReportDocument.close() call in your unload method.  You would need to check to make sure that the document was available and that you weren&#39;t loading parameters.  I&#39;m sure that this would work. </p><p>Rob Horne</p><p><a href="/blog/10">Rob&#39;s blog - http://diamond.businessobjects.com/blog/10</a></p>

  • MTS with too many OS processes

    Hi,today i changed some connections to MTS (shared server)
    db version is 10.2.0.3
    os version aix 5.3.5
    after 3 hours, i take the follownig error, no oracle proses can be forked after.
    i returned to dedicated server, now everythnig is ok.
    at the time of problem, # of oracle prosecces see in the OS was 4000 which is the OS limit for max process a user can create.
    it is 2000 in dedicated server case.
    what may be the cause.
    thanks,
    ORA-27300: OS system dependent operation:fork failed with status: 11
    ORA-27301: OS failure message: Resource temporarily unavailable
    ORA-27302: failure occurred at: skgpspawn3

    #dispatchers are 2. each with 250 connections.
    shared_servers=10
    max_shared_servers=40
    in the OS, i saw 4000 oracle processes in mixed architecture (dedicated and shared)
    whe i turned to just dedicated, i see 2000 processes.
    it must be the reverse.

  • Too many LISTENER processes (11gR2 Grid Infrastructure (2 nodes))

    Greetings -
    I get an alert that says that my LISTENER is down (EM Alert Details). It suggests a corrective action
    to stop the current running LISTENER and start it again using the listener parameter (listener.ora) from
    the database (RDBMS) home. There are two (2) LISTENER processes running (ps -ef | grep LISTENER) .
    One process is running from the grid home and the other from the database home however only
    the one running from the grid home has a listener parameter file (listener.ora) there are no others.
    To confuse me even further the documentation says that I should not set the 'local_listener' parameter
    and that the Oracle Agent will maintain this setting.
    Any suggestions ?
    Thanks in advance.
    Brian

    Thanks Rodrigo,
    That was VERY helpful.
    I disabled the old listener and then
    I was able to create a new listener with the correct settings.
    I can see the instances on each node using this
    expression.
    lsnrctl status NEW_LISTENER
    However this shows on the first node that +ASM1, DM3, DM31
    are available on the second node I see only +ASM2 but nothing else.
    I was expecting DM3, DM32 .
    Now when I first created the new listener I read that the 'local_listener'
    setting need NOT be set. When I attemptied to unset that parameter then
    I lost the local instances. I reset the local_listener as before
    and the local instance on node one returned. Not on node two however.
    My question: Do I need to set the 'local_listener' on each instance to the same
    value or to different values to reflect which node they are configured for ?
    I cannot see it now but I remember there is a section that references the
    first node 'node_one-vip' .
    Should the second node's local_listener section be 'node_two-vip' ?
    Now if it need not be set this then something else has to occur to make it work.
    Sorry for not being more brief,
    Brian

  • RFC calls are taking too many work process -- system knock out

    Hi,
    I have an interface remote function, which is going to be called by a java program.
    Data is going to be sent to the system, processed and sent back syncronous to the caller.
    The calls are working on SAP tables, so I needed to lock and unlock the tables. The java program
    is opening many parallell threads and starts them the same time.
    That means, that the sap system is getting attacked by many rfc calls on the same function, with the
    same user at the same time.
    The system has in development 15 dialog work processes set up. If I run that with up to 15 parallell rfc calls, all is working ok!
    Let me now explain the problem:
    I have programmed the table lock, that it´s trying to lock the table at the beginning of the function.
    If it´s not possible it tries it again. At first I have just inserted a one second wait and let that run maximum 3 times. If the table is still locked, it breaks down with an error.
    But because the calls come nearly to exactly the same time to the system, the first call locks all others out, and the rest ran out of the 3 seconds and ended up with an error.
    So I tried to build an endless loop, which is just ending, when the table could be locked again, or when the runtime of 5 seconds has reached. That means, it´s not waiting for a second, if the table is locked, but it´s trying again and again up to 5 seconds.
    That is all ok, because sometime the table is free again and all calls are then processed alright.
    BUT if I now run that with MORE than 15 rfc calls from the java program (15 dialog processes are set up), the system got knocked out! It is using all free work processes for the RFC calls and get stucked. I think, the first call is locking the table, and the got stopped by the system. And then all the others are running in the endless loop....
    So, shouldn´t be there a limit for dialog processes taken by RFC calls? For example here for this user? In this case it should f.e. be set to 10 free processes with 5, which are reserved for other users...
    Any advices?
    The second is, how can I change the lock mechanism, that I don´t use an endless loop? Waiting for one second and doing that 3 times, is not good enough... Because all the rfc calls wait then for one second, up to 3 times, and end with an error....
    Is it possible to wait for half seconds, or defined milli seconds?
    Thank you for all advices!

    Hi,
    What I have understood is you are trying to lock the table in a loop and just checking the duration by explicitly putting wait statement.
    Hope you are NOT locking the entire table rather a particular record in each lock.
    No need to use explicit wait statement rather its better to let SAP thinks when to lock the table T1 when its already locked by another work process. So just set the wait parameter for the Enqueue function module as 'X' and check how it behaves. Until the table is not unlocked the process will wait.
    If you see the wait parameter for the Enqueue function module is not available then create your own lock object for the table and use that. Make sure its getting dequeued else you can understand better
    Cheers
    Somnath

  • Too many time to open a session with oracle odbc

    I have to migrate an internet site in Sql Server to Oracle.
    When I connect Oracle Database with Oracle ODBC, it takes 2 or 3 seconds.
    So if i have 8 or 10 recordset to open, it takes 20 s.
    But when sessions are open, they live about 1 m and during this time i don't have problem to connect to the database.When i don't use the site during more than 1 m, all sessions are closed and so i have to wait.
    How can i connect to the database quickly the first time?

    Are you using connection pooling? Are you pre-allocating connections on startup?
    Justin

  • Oracle 10g  Source DB Capture Process : Waiting for dictionary redo?

    Hi to all,
    Situation: Source DB waiting for dictionary redo first SCN
    First SCN = 314353677
    Start SCN = 644568684
    current SCN =779444676
    Don't now how to trouble shoot
    Previous error is Pause for flow control
    Now it is prompting dictionary redo first SCN
    How to trouble shoot Step by Step
    PLeeaasssssssse expertssssss need help

    this are all the files present in the archive folder
    1_2505_705753337.log  1_4218_705753337.log  1_5932_705753337.log  1_764_705753337.log   1_9360_705753337.log
    1_2506_705753337.log  1_4219_705753337.log  1_5933_705753337.log  1_7647_705753337.log  1_9361_705753337.log
    1_250_705753337.log   1_4220_705753337.log  1_5934_705753337.log  1_7648_705753337.log  1_9362_705753337.log
    1_2507_705753337.log  1_4221_705753337.log  1_5935_705753337.log  1_7649_705753337.log  1_9363_705753337.log
    1_2508_705753337.log  1_4222_705753337.log  1_5936_705753337.log  1_7650_705753337.log  1_9364_705753337.log
    1_2509_705753337.log  1_4223_705753337.log  1_593_705753337.log   1_7651_705753337.log  1_9365_705753337.log
    1_2510_705753337.log  1_4224_705753337.log  1_5937_705753337.log  1_7652_705753337.log  1_9366_705753337.log
    1_2511_705753337.log  1_4225_705753337.log  1_5938_705753337.log  1_7653_705753337.log  1_936_705753337.log
    1_2512_705753337.log  1_4226_705753337.log  1_5939_705753337.log  1_7654_705753337.log  1_9367_705753337.log
    1_2513_705753337.log  1_422_705753337.log   1_5940_705753337.log  1_7655_705753337.log  1_9368_705753337.log
    1_2514_705753337.log  1_4227_705753337.log  1_5941_705753337.log  1_7656_705753337.log  1_9369_705753337.log
    1_2515_705753337.log  1_4228_705753337.log  1_5942_705753337.log  1_765_705753337.log   1_93_705753337.log
    1_2516_705753337.log  1_4229_705753337.log  1_5943_705753337.log  1_7657_705753337.log  1_9370_705753337.log
    1_251_705753337.log   1_4230_705753337.log  1_5944_705753337.log  1_7658_705753337.log  1_9371_705753337.log
    1_2517_705753337.log  1_4231_705753337.log  1_5945_705753337.log  1_7659_705753337.log  1_9372_705753337.log
    1_2518_705753337.log  1_4232_705753337.log  1_5946_705753337.log  1_7660_705753337.log  1_9373_705753337.log
    1_2519_705753337.log  1_4233_705753337.log  1_594_705753337.log   1_7661_705753337.log  1_9374_705753337.log
    1_2520_705753337.log  1_4234_705753337.log  1_5947_705753337.log  1_7662_705753337.log  1_9375_705753337.log
    1_2521_705753337.log  1_4235_705753337.log  1_5948_705753337.log  1_7663_705753337.log  1_9376_705753337.log
    1_2522_705753337.log  1_4236_705753337.log  1_5949_705753337.log  1_7664_705753337.log  1_937_705753337.log
    1_2523_705753337.log  1_423_705753337.log   1_5950_705753337.log  1_7665_705753337.log  1_9377_705753337.log
    1_2524_705753337.log  1_4237_705753337.log  1_5951_705753337.log  1_7666_705753337.log  1_9378_705753337.log
    1_2525_705753337.log  1_4238_705753337.log  1_5952_705753337.log  1_766_705753337.log   1_9379_705753337.log
    1_2526_705753337.log  1_4239_705753337.log  1_5953_705753337.log  1_7667_705753337.log  1_9380_705753337.log
    1_252_705753337.log   1_4240_705753337.log  1_5954_705753337.log  1_7668_705753337.log  1_9381_705753337.log
    1_2527_705753337.log  1_4241_705753337.log  1_5955_705753337.log  1_7669_705753337.log  1_9382_705753337.log
    1_2528_705753337.log  1_4242_705753337.log  1_5956_705753337.log  1_76_705753337.log    1_9383_705753337.log
    1_2529_705753337.log  1_4243_705753337.log  1_595_705753337.log   1_7670_705753337.log  1_9384_705753337.log
    1_2530_705753337.log  1_4244_705753337.log  1_5957_705753337.log  1_7671_705753337.log  1_9385_705753337.log
    1_2531_705753337.log  1_4245_705753337.log  1_5958_705753337.log  1_7672_705753337.log  1_9386_705753337.log
    1_2532_705753337.log  1_4246_705753337.log  1_5959_705753337.log  1_7673_705753337.log  1_938_705753337.log
    1_2533_705753337.log  1_424_705753337.log   1_5960_705753337.log  1_7674_705753337.log  1_9387_705753337.log
    1_2534_705753337.log  1_4247_705753337.log  1_5961_705753337.log  1_7675_705753337.log  1_9388_705753337.log
    1_2535_705753337.log  1_4248_705753337.log  1_5962_705753337.log  1_7676_705753337.log  1_9389_705753337.log
    1_2536_705753337.log  1_4249_705753337.log  1_5963_705753337.log  1_767_705753337.log   1_9390_705753337.log
    1_253_705753337.log   1_4250_705753337.log  1_5964_705753337.log  1_7677_705753337.log  1_9391_705753337.log
    1_2537_705753337.log  1_4251_705753337.log  1_5965_705753337.log  1_7678_705753337.log  1_9392_705753337.log
    1_2538_705753337.log  1_4252_705753337.log  1_5966_705753337.log  1_7679_705753337.log  1_9393_705753337.log
    1_2539_705753337.log  1_4253_705753337.log  1_596_705753337.log   1_7680_705753337.log  1_9394_705753337.log
    1_2540_705753337.log  1_4254_705753337.log  1_5967_705753337.log  1_7681_705753337.log  1_9395_705753337.log
    1_2541_705753337.log  1_4255_705753337.log  1_5968_705753337.log  1_7682_705753337.log  1_9396_705753337.log
    1_2542_705753337.log  1_4256_705753337.log  1_5969_705753337.log  1_7683_705753337.log  1_939_705753337.log
    1_2543_705753337.log  1_425_705753337.log   1_59_705753337.log    1_7684_705753337.log  1_9397_705753337.log
    1_2544_705753337.log  1_4257_705753337.log  1_5970_705753337.log  1_7685_705753337.log  1_9398_705753337.log
    1_2545_705753337.log  1_4258_705753337.log  1_5971_705753337.log  1_7686_705753337.log  1_9399_705753337.log
    1_2546_705753337.log  1_4259_705753337.log  1_5972_705753337.log  1_768_705753337.log   1_9400_705753337.log
    1_254_705753337.log   1_4260_705753337.log  1_5973_705753337.log  1_7687_705753337.log  1_9401_705753337.log
    1_2547_705753337.log  1_4261_705753337.log  1_5974_705753337.log  1_7688_705753337.log  1_9402_705753337.log
    1_2548_705753337.log  1_4262_705753337.log  1_5975_705753337.log  1_7689_705753337.log  1_9403_705753337.log
    1_2549_705753337.log  1_4263_705753337.log  1_5976_705753337.log  1_7690_705753337.log  1_9404_705753337.log
    1_2550_705753337.log  1_4264_705753337.log  1_597_705753337.log   1_7691_705753337.log  1_9405_705753337.log
    1_2551_705753337.log  1_4265_705753337.log  1_5977_705753337.log  1_7692_705753337.log  1_9406_705753337.log
    1_2552_705753337.log  1_4266_705753337.log  1_5978_705753337.log  1_7693_705753337.log  1_940_705753337.log
    1_2553_705753337.log  1_426_705753337.log   1_5979_705753337.log  1_7694_705753337.log  1_9407_705753337.log
    1_2554_705753337.log  1_4267_705753337.log  1_5980_705753337.log  1_7695_705753337.log  1_9408_705753337.log
    1_2555_705753337.log  1_4268_705753337.log  1_5981_705753337.log  1_7696_705753337.log  1_9409_705753337.log
    1_2556_705753337.log  1_4269_705753337.log  1_5982_705753337.log  1_769_705753337.log   1_9410_705753337.log
    1_255_705753337.log   1_42_705753337.log    1_5983_705753337.log  1_7697_705753337.log  1_9411_705753337.log
    1_2557_705753337.log  1_4270_705753337.log  1_5984_705753337.log  1_7698_705753337.log  1_9412_705753337.log
    1_2558_705753337.log  1_4271_705753337.log  1_5985_705753337.log  1_7699_705753337.log  1_9413_705753337.log
    1_2559_705753337.log  1_4272_705753337.log  1_5986_705753337.log  1_7700_705753337.log  1_9414_705753337.log
    1_2560_705753337.log  1_4273_705753337.log  1_598_705753337.log   1_7701_705753337.log  1_9415_705753337.log
    1_2561_705753337.log  1_4274_705753337.log  1_5987_705753337.log  1_7702_705753337.log  1_9416_705753337.log
    1_2562_705753337.log  1_4275_705753337.log  1_5988_705753337.log  1_7703_705753337.log  1_941_705753337.log
    1_2563_705753337.log  1_4276_705753337.log  1_5989_705753337.log  1_7704_705753337.log  1_9417_705753337.log
    1_2564_705753337.log  1_427_705753337.log   1_5990_705753337.log  1_7705_705753337.log  1_9418_705753337.log
    1_2565_705753337.log  1_4277_705753337.log  1_5991_705753337.log  1_7_705753337.log     1_9419_705753337.log
    1_2566_705753337.log  1_4278_705753337.log  1_5992_705753337.log  1_7706_705753337.log  1_9420_705753337.log
    1_256_705753337.log   1_4279_705753337.log  1_5993_705753337.log  1_770_705753337.log   1_9421_705753337.log
    1_2567_705753337.log  1_4280_705753337.log  1_5994_705753337.log  1_7707_705753337.log  1_9422_705753337.log
    1_2568_705753337.log  1_4281_705753337.log  1_5995_705753337.log  1_7708_705753337.log  1_9423_705753337.log
    1_2569_705753337.log  1_4282_705753337.log  1_5996_705753337.log  1_7709_705753337.log  1_9424_705753337.log
    1_25_705753337.log    1_4283_705753337.log  1_599_705753337.log   1_7710_705753337.log  1_9425_705753337.log
    1_2570_705753337.log  1_4284_705753337.log  1_5997_705753337.log  1_7711_705753337.log  1_9426_705753337.log
    1_2571_705753337.log  1_4285_705753337.log  1_5998_705753337.log  1_7712_705753337.log  1_942_705753337.log
    1_2572_705753337.log  1_4286_705753337.log  1_5999_705753337.log  1_7713_705753337.log  1_9427_705753337.log
    1_2573_705753337.log  1_428_705753337.log   1_6000_705753337.log  1_7714_705753337.log  1_9428_705753337.log
    1_2574_705753337.log  1_4287_705753337.log  1_6001_705753337.log  1_7715_705753337.log  1_9429_705753337.log
    1_2575_705753337.log  1_4288_705753337.log  1_6002_705753337.log  1_7716_705753337.log  1_9430_705753337.log
    1_2576_705753337.log  1_4289_705753337.log  1_6003_705753337.log  1_771_705753337.log   1_9431_705753337.log
    1_257_705753337.log   1_4290_705753337.log  1_6004_705753337.log  1_7717_705753337.log  1_9432_705753337.log
    1_2577_705753337.log  1_4291_705753337.log  1_6005_705753337.log  1_7718_705753337.log  1_9433_705753337.log
    1_2578_705753337.log  1_4292_705753337.log  1_6006_705753337.log  1_7719_705753337.log  1_9434_705753337.log
    1_2579_705753337.log  1_4293_705753337.log  1_600_705753337.log   1_7720_705753337.log  1_9435_705753337.log
    1_2580_705753337.log  1_4294_705753337.log  1_6007_705753337.log  1_7721_705753337.log  1_9436_705753337.log
    1_2581_705753337.log  1_4295_705753337.log  1_6008_705753337.log  1_7722_705753337.log  1_943_705753337.log
    1_2582_705753337.log  1_4296_705753337.log  1_6009_705753337.log  1_7723_705753337.log  1_9437_705753337.log
    1_2583_705753337.log  1_429_705753337.log   1_6010_705753337.log  1_7724_705753337.log  1_9438_705753337.log
    1_2584_705753337.log  1_4297_705753337.log  1_6011_705753337.log  1_7725_705753337.log  1_9439_705753337.log
    1_2585_705753337.log  1_4298_705753337.log  1_6012_705753337.log  1_7726_705753337.log  1_9440_705753337.log
    1_2586_705753337.log  1_4299_705753337.log  1_6013_705753337.log  1_772_705753337.log   1_9441_705753337.log
    1_258_705753337.log   1_4300_705753337.log  1_6014_705753337.log  1_7727_705753337.log  1_9442_705753337.log
    1_2587_705753337.log  1_4301_705753337.log  1_6015_705753337.log  1_7728_705753337.log  1_9443_705753337.log
    1_2588_705753337.log  1_4302_705753337.log  1_6016_705753337.log  1_7729_705753337.log  1_9444_705753337.log
    1_2589_705753337.log  1_4303_705753337.log  1_601_705753337.log   1_7730_705753337.log  1_9445_705753337.log
    1_2590_705753337.log  1_4304_705753337.log  1_6017_705753337.log  1_7731_705753337.log  1_9446_705753337.log
    1_2591_705753337.log  1_4305_705753337.log  1_6018_705753337.log  1_7732_705753337.log  1_944_705753337.log
    1_2592_705753337.log  1_4306_705753337.log  1_6019_705753337.log  1_7733_705753337.log  1_9447_705753337.log
    1_2593_705753337.log  1_430_705753337.log   1_6020_705753337.log  1_7734_705753337.log  1_9448_705753337.log
    1_2594_705753337.log  1_4307_705753337.log  1_6021_705753337.log  1_7735_705753337.log  1_9449_705753337.log
    1_2595_705753337.log  1_4308_705753337.log  1_6022_705753337.log  1_7736_705753337.log  1_9450_705753337.log
    1_2596_705753337.log  1_4309_705753337.log  1_6023_705753337.log  1_773_705753337.log   1_9451_705753337.log
    1_259_705753337.log   1_4310_705753337.log  1_6024_705753337.log  1_7737_705753337.log  1_9452_705753337.log
    1_2597_705753337.log  1_4311_705753337.log  1_6025_705753337.log  1_7738_705753337.log  1_9453_705753337.log
    1_2598_705753337.log  1_4312_705753337.log  1_6026_705753337.log  1_7739_705753337.log  1_9454_705753337.log
    1_2599_705753337.log  1_4313_705753337.log  1_602_705753337.log   1_7740_705753337.log  1_9455_705753337.log
    1_2600_705753337.log  1_4314_705753337.log  1_6027_705753337.log  1_7741_705753337.log  1_9456_705753337.log
    1_2601_705753337.log  1_4315_705753337.log  1_6028_705753337.log  1_7742_705753337.log  1_945_705753337.log
    1_2602_705753337.log  1_4316_705753337.log  1_6029_705753337.log  1_7743_705753337.log  1_9457_705753337.log
    1_2603_705753337.log  1_431_705753337.log   1_6030_705753337.log  1_7744_705753337.log  1_9458_705753337.log
    1_2604_705753337.log  1_4317_705753337.log  1_6031_705753337.log  1_7745_705753337.log  1_9459_705753337.log
    1_2605_705753337.log  1_4318_705753337.log  1_6032_705753337.log  1_7746_705753337.log  1_9460_705753337.log
    1_2606_705753337.log  1_4319_705753337.log  1_6033_705753337.log  1_774_705753337.log   1_9461_705753337.log
    1_260_705753337.log   1_4320_705753337.log  1_6034_705753337.log  1_7747_705753337.log  1_9462_705753337.log
    1_2607_705753337.log  1_4321_705753337.log  1_6035_705753337.log  1_7748_705753337.log  1_9463_705753337.log
    1_2608_705753337.log  1_4322_705753337.log  1_6036_705753337.log  1_7749_705753337.log  1_9464_705753337.log
    1_2609_705753337.log  1_4323_705753337.log  1_603_705753337.log   1_7750_705753337.log  1_9465_705753337.log
    1_2610_705753337.log  1_4324_705753337.log  1_6037_705753337.log  1_7751_705753337.log  1_9466_705753337.log
    1_2611_705753337.log  1_4325_705753337.log  1_6038_705753337.log  1_7752_705753337.log  1_946_705753337.log
    1_2612_705753337.log  1_4326_705753337.log  1_6039_705753337.log  1_7753_705753337.log  1_9467_705753337.log
    1_2613_705753337.log  1_432_705753337.log   1_6040_705753337.log  1_7754_705753337.log  1_9468_705753337.log
    1_2614_705753337.log  1_4327_705753337.log  1_6041_705753337.log  1_7755_705753337.log  1_9469_705753337.log
    1_2615_705753337.log  1_4328_705753337.log  1_6042_705753337.log  1_7756_705753337.log  1_94_705753337.log
    1_2616_705753337.log  1_4329_705753337.log  1_6043_705753337.log  1_775_705753337.log   1_9470_705753337.log
    1_261_705753337.log   1_4330_705753337.log  1_6044_705753337.log  1_7757_705753337.log  1_9471_705753337.log
    1_2617_705753337.log  1_4331_705753337.log  1_6045_705753337.log  1_7758_705753337.log  1_9472_705753337.log
    1_2618_705753337.log  1_4332_705753337.log  1_6046_705753337.log  1_7759_705753337.log  1_9473_705753337.log
    1_2619_705753337.log  1_4333_705753337.log  1_604_705753337.log   1_7760_705753337.log  1_9474_705753337.log
    1_2620_705753337.log  1_4334_705753337.log  1_6047_705753337.log  1_7761_705753337.log  1_9475_705753337.log
    1_2621_705753337.log  1_4335_705753337.log  1_6048_705753337.log  1_7762_705753337.log  1_9476_705753337.log
    1_2622_705753337.log  1_4336_705753337.log  1_6049_705753337.log  1_7763_705753337.log  1_947_705753337.log
    1_2623_705753337.log  1_433_705753337.log   1_6050_705753337.log  1_7764_705753337.log  1_9477_705753337.log
    1_2624_705753337.log  1_4337_705753337.log  1_6051_705753337.log  1_7765_705753337.log  1_9478_705753337.log
    1_2625_705753337.log  1_4338_705753337.log  1_6052_705753337.log  1_7766_705753337.log  1_9479_705753337.log
    1_2626_705753337.log  1_4339_705753337.log  1_6053_705753337.log  1_776_705753337.log   1_9480_705753337.log
    1_262_705753337.log   1_4340_705753337.log  1_6054_705753337.log  1_7767_705753337.log  1_9481_705753337.log
    1_2627_705753337.log  1_4341_705753337.log  1_6055_705753337.log  1_7768_705753337.log  1_9482_705753337.log
    1_2628_705753337.log  1_4342_705753337.log  1_6056_705753337.log  1_7769_705753337.log  1_9483_705753337.log
    1_2629_705753337.log  1_4343_705753337.log  1_605_705753337.log   1_77_705753337.log    1_9484_705753337.log
    1_2630_705753337.log  1_4344_705753337.log  1_6057_705753337.log  1_7770_705753337.log  1_9485_705753337.log
    1_2631_705753337.log  1_4345_705753337.log  1_6058_705753337.log  1_7771_705753337.log  1_9486_705753337.log
    1_2632_705753337.log  1_4346_705753337.log  1_6059_705753337.log  1_7772_705753337.log  1_948_705753337.log
    1_2633_705753337.log  1_434_705753337.log   1_6060_705753337.log  1_7773_705753337.log  1_9487_705753337.log
    1_2634_705753337.log  1_4347_705753337.log  1_6061_705753337.log  1_7774_705753337.log  1_9488_705753337.log
    1_2635_705753337.log  1_4348_705753337.log  1_6062_705753337.log  1_7775_705753337.log  1_9489_705753337.log
    1_2636_705753337.log  1_4349_705753337.log  1_6063_705753337.log  1_7776_705753337.log  1_9490_705753337.log
    1_263_705753337.log   1_4350_705753337.log  1_6064_705753337.log  1_777_705753337.log   1_9491_705753337.log
    1_2637_705753337.log  1_4351_705753337.log  1_6065_705753337.log  1_7777_705753337.log  1_9492_705753337.log
    1_2638_705753337.log  1_4352_705753337.log  1_6066_705753337.log  1_7778_705753337.log  1_9493_705753337.log
    1_2639_705753337.log  1_4353_705753337.log  1_606_705753337.log   1_7779_705753337.log  1_9494_705753337.log
    1_2640_705753337.log  1_4354_705753337.log  1_6067_705753337.log  1_7780_705753337.log  1_9495_705753337.log
    1_2641_705753337.log  1_4355_705753337.log  1_6068_705753337.log  1_7781_705753337.log  1_9496_705753337.log
    1_2642_705753337.log  1_4356_705753337.log  1_6069_705753337.log  1_7782_705753337.log  1_949_705753337.log
    1_2643_705753337.log  1_435_705753337.log   1_60_705753337.log    1_7783_705753337.log  1_9497_705753337.log
    1_2644_705753337.log  1_4357_705753337.log  1_6070_705753337.log  1_7784_705753337.log  1_9498_705753337.log
    1_2645_705753337.log  1_4358_705753337.log  1_6071_705753337.log  1_7785_705753337.log  1_9499_705753337.log
    1_2646_705753337.log  1_4359_705753337.log  1_6072_705753337.log  1_7786_705753337.log  1_9500_705753337.log
    1_264_705753337.log   1_4360_705753337.log  1_6073_705753337.log  1_778_705753337.log   1_9501_705753337.log
    1_2647_705753337.log  1_4361_705753337.log  1_6074_705753337.log  1_7787_705753337.log  1_9502_705753337.log
    1_2648_705753337.log  1_4362_705753337.log  1_6075_705753337.log  1_7788_705753337.log  1_9503_705753337.log
    1_2649_705753337.log  1_4363_705753337.log  1_6076_705753337.log  1_7789_705753337.log  1_9504_705753337.log
    1_2650_705753337.log  1_4364_705753337.log  1_607_705753337.log   1_7790_705753337.log  1_9505_705753337.log
    1_2651_705753337.log  1_4365_705753337.log  1_6077_705753337.log  1_7791_705753337.log  1_9506_705753337.log
    1_2652_705753337.log  1_4366_705753337.log  1_6078_705753337.log  1_7792_705753337.log  1_950_705753337.log
    1_2653_705753337.log  1_436_705753337.log   1_6079_705753337.log  1_7793_705753337.log  1_9507_705753337.log
    1_2654_705753337.log  1_4367_705753337.log  1_6080_705753337.log  1_7794_705753337.log  1_9508_705753337.log
    1_2655_705753337.log  1_4368_705753337.log  1_6081_705753337.log  1_7795_705753337.log  1_9509_705753337.log
    1_2656_705753337.log  1_4369_705753337.log  1_6082_705753337.log  1_7796_705753337.log  1_9510_705753337.log
    1_265_705753337.log   1_43_705753337.log    1_6083_705753337.log  1_779_705753337.log   1_9511_705753337.log
    1_2657_705753337.log  1_4370_705753337.log  1_6084_705753337.log  1_7797_705753337.log  1_9512_705753337.log
    1_2658_705753337.log  1_4371_705753337.log  1_6085_705753337.log  1_7798_705753337.log  1_9513_705753337.log
    1_2659_705753337.log  1_4372_705753337.log  1_6086_705753337.log  1_7799_705753337.log  1_9514_705753337.log
    1_2660_705753337.log  1_4373_705753337.log  1_608_705753337.log   1_7800_705753337.log  1_9515_705753337.log
    1_2661_705753337.log  1_4374_705753337.log  1_6087_705753337.log  1_7801_705753337.log  1_9516_705753337.log
    1_2662_705753337.log  1_4375_705753337.log  1_6088_705753337.log  1_7802_705753337.log  1_951_705753337.log
    1_2663_705753337.log  1_4376_705753337.log  1_6089_705753337.log  1_7803_705753337.log  1_9517_705753337.log
    1_2664_705753337.log  1_437_705753337.log   1_6090_705753337.log  1_7804_705753337.log  1_9518_705753337.log
    1_2665_705753337.log  1_4377_705753337.log  1_6091_705753337.log  1_7805_705753337.log  1_952_705753337.log
    1_2666_705753337.log  1_4378_705753337.log  1_6092_705753337.log  1_7806_705753337.log  1_953_705753337.log
    1_266_705753337.log   1_4379_705753337.log  1_6093_705753337.log  1_780_705753337.log   1_954_705753337.log
    1_2667_705753337.log  1_4380_705753337.log  1_6094_705753337.log  1_7807_705753337.log  1_955_705753337.log
    1_2668_705753337.log  1_4381_705753337.log  1_6095_705753337.log  1_7808_705753337.log  1_956_705753337.log
    1_2669_705753337.log  1_4382_705753337.log  1_6096_705753337.log  1_7809_705753337.log  1_95_705753337.log
    1_26_705753337.log    1_4383_705753337.log  1_609_705753337.log   1_7810_705753337.log  1_957_705753337.log
    1_2670_705753337.log  1_4384_705753337.log  1_6097_705753337.log  1_7811_705753337.log  1_958_705753337.log
    1_2671_705753337.log  1_4385_705753337.log  1_6098_705753337.log  1_7812_705753337.log  1_959_705753337.log
    1_2672_705753337.log  1_4386_705753337.log  1_6099_705753337.log  1_7813_705753337.log  1_960_705753337.log
    1_2673_705753337.log  1_438_705753337.log   1_6100_705753337.log  1_7814_705753337.log  1_961_705753337.log
    1_2674_705753337.log  1_4387_705753337.log  1_6101_705753337.log  1_7815_705753337.log  1_962_705753337.log
    1_2675_705753337.log  1_4388_705753337.log  1_6102_705753337.log  1_7816_705753337.log  1_963_705753337.log
    1_2676_705753337.log  1_4389_705753337.log  1_6103_705753337.log  1_781_705753337.log   1_964_705753337.log
    1_267_705753337.log   1_4390_705753337.log  1_6104_705753337.log  1_7817_705753337.log  1_965_705753337.log
    1_2677_705753337.log  1_4391_705753337.log  1_6105_705753337.log  1_7818_705753337.log  1_966_705753337.log
    1_2678_705753337.log  1_4392_705753337.log  1_6106_705753337.log  1_7819_705753337.log  1_96_705753337.log
    1_2679_705753337.log  1_4393_705753337.log  1_610_705753337.log   1_7820_705753337.log  1_967_705753337.log
    1_2680_705753337.log  1_4394_705753337.log  1_6107_705753337.log  1_7821_705753337.log  1_968_705753337.log
    1_2681_705753337.log  1_4395_705753337.log  1_6108_705753337.log  1_7822_705753337.log  1_969_705753337.log
    1_2682_705753337.log  1_4396_705753337.log  1_6109_705753337.log  1_7823_705753337.log  1_9_705753337.log
    1_2683_705753337.log  1_439_705753337.log   1_6110_705753337.log  1_7824_705753337.log  1_970_705753337.log
    1_2684_705753337.log  1_4397_705753337.log  1_6111_705753337.log  1_7825_705753337.log  1_971_705753337.log
    1_2685_705753337.log  1_4398_705753337.log  1_6112_705753337.log  1_7826_705753337.log  1_972_705753337.log
    1_2686_705753337.log  1_4399_705753337.log  1_6113_705753337.log  1_782_705753337.log   1_973_705753337.log
    1_268_705753337.log   1_4400_705753337.log  1_6114_705753337.log  1_7827_705753337.log  1_974_705753337.log
    1_2687_705753337.log  1_4401_705753337.log  1_6115_705753337.log  1_7828_705753337.log  1_975_705753337.log
    1_2688_705753337.log  1_4402_705753337.log  1_6116_705753337.log  1_7829_705753337.log  1_976_705753337.log
    1_2689_705753337.log  1_4403_705753337.log  1_611_705753337.log   1_7830_705753337.log  1_97_705753337.log
    1_2690_705753337.log  1_4404_705753337.log  1_6117_705753337.log  1_7831_705753337.log  1_977_705753337.log
    1_2691_705753337.log  1_4405_705753337.log  1_6118_705753337.log  1_7832_705753337.log  1_978_705753337.log
    1_2692_705753337.log  1_4406_705753337.log  1_6119_705753337.log  1_7833_705753337.log  1_979_705753337.log
    1_2693_705753337.log  1_440_705753337.log   1_6120_705753337.log  1_7834_705753337.log  1_980_705753337.log
    1_2694_705753337.log  1_4407_705753337.log  1_6121_705753337.log  1_7835_705753337.log  1_981_705753337.log
    1_2695_705753337.log  1_4408_705753337.log  1_6122_705753337.log  1_7836_705753337.log  1_982_705753337.log
    1_2696_705753337.log  1_4409_705753337.log  1_6123_705753337.log  1_783_705753337.log   1_983_705753337.log
    1_269_705753337.log   1_4410_705753337.log  1_6124_705753337.log  1_7837_705753337.log  1_984_705753337.log
    1_2697_705753337.log  1_4411_705753337.log  1_6125_705753337.log  1_7838_705753337.log  1_985_705753337.log
    1_2698_705753337.log  1_4412_705753337.log  1_6126_705753337.log  1_7839_705753337.log  1_986_705753337.log
    1_2699_705753337.log  1_4413_705753337.log  1_612_705753337.log   1_7840_705753337.log  1_98_705753337.log
    1_2700_705753337.log  1_4414_705753337.log  1_6127_705753337.log  1_7841_705753337.log  1_987_705753337.log
    1_2701_705753337.log  1_4415_705753337.log  1_6128_705753337.log  1_7842_705753337.log  1_988_705753337.log
    1_2702_705753337.log  1_4416_705753337.log  1_6129_705753337.log  1_7843_705753337.log  1_989_705753337.log
    1_2703_705753337.log  1_441_705753337.log   1_6130_705753337.log  1_7844_705753337.log  1_990_705753337.log
    1_2704_705753337.log  1_4417_705753337.log  1_6131_705753337.log  1_7845_705753337.log  1_991_705753337.log
    1_2705_705753337.log  1_4418_705753337.log  1_6132_705753337.log  1_7846_705753337.log  1_992_705753337.log
    1_2_705753337.log     1_4419_705753337.log  1_6133_705753337.log  1_784_705753337.log   1_993_705753337.log
    1_2706_705753337.log  1_4420_705753337.log  1_6134_705753337.log  1_7847_705753337.log  1_994_705753337.log
    1_270_705753337.log   1_4421_705753337.log  1_6135_705753337.log  1_7848_705753337.log  1_995_705753337.log
    1_2707_705753337.log  1_4422_705753337.log  1_6136_705753337.log  1_7849_705753337.log  1_996_705753337.log
    1_2708_705753337.log  1_4423_705753337.log  1_613_705753337.log   1_7850_705753337.log  1_99_705753337.log
    1_2709_705753337.log  1_4424_705753337.log  1_6137_705753337.log  1_7851_705753337.log  1_997_705753337.log
    1_2710_705753337.log  1_4425_705753337.log  1_6138_705753337.log  1_7852_705753337.log  1_998_705753337.log
    1_2711_705753337.log  1_4426_705753337.log  1_6139_705753337.log  1_7853_705753337.log  1_999_705753337.log
    1_2712_705753337.log  1_442_705753337.log   1_6140_705753337.log  1_7854_705753337.log
    1_2713_705753337.log  1_4427_705753337.log  1_6141_705753337.log  1_7855_705753337.logEdited by: user13640691 on Feb 23, 2011 2:35 AM

  • ADF panel opening too many JDBC Thin Client database sessions.

    Hi All,
    I have several ADF Panels, which allows the user to run a few simple queries against an Oracle database done using ADF view objects and ADF view links and ADF application module.
    Each ADF panel as I said contains several View Link queries, and links under the form of Jbuttons to other ADF Panels running other ADF View Links.
    Running the ADF Panel as described here opens up to 21 database sessions displaying as “JDBC Thin Client” when I look them up from v$session.
    Why do I end up with that many database sessions.
    Why doesn’t it just use one or two database sessions to run all these View Links? It seems that it is opening one database session for each of these view links.
    How can I change this destructive behavior? I only one to see one or two database sessions for the entire ADF panel no matter how many ADF View Links it contains.
    Your suggestions are most appreciated.
    Thanks.
    Bobby A.

    Thanks for your response.
    I took a quick look at the docs you pointed me to. It seems that I can set some parameters in bc4j.xcfg of each application module Home to control number of database connections that the application module will create. In that case maybe you can recommend which parameters and what value they should be set to.
    Your response will be most helpful as my background is rather in database admin and not java.
    Thanks.
    Bobby A.

  • Uploading photo in oracle 10g express edition

    Hi,
    I want to upload photo in my database running on oracle 10g express edition.This process must handle simultaneous uploading and with minimum error. Problem is the site is online and anyone can upload garbage,etc.so i am planning to collect images through email and then photo would be uploaded by some data entry operator. please suggest me some process
    Thanks

    878927 wrote:
    How can use these loader tools? and what will be the advantage by going through these tools?please explain.Another Condition is i have to scan the photos before uploading it to databaseThere are instructions on how to use SQL*LOADER in the on-line documentation. I meant to say that you have to decide the best way to load the data. I just listed some examples on possible ways it can be done.
    Apex is a database application that can be used to generate web pages based on database tables. It can also load files from clients. You can read about Apex in the Apex forums here on OTN or in the on-linedocumentation

  • Migration from Informix 9.4 to Oracle 10g

    We have to perform a migration from Informix 9.4 to Oracle 10g. Many tables, many data and many stored procs.
    We use the Online mode and the imports finish with any errors, but it has not recovered any stored procedures or we can't view the Informix Stored Procedures in the Source Model in the workbench.
    In the importation log appears as no found procedures, but under owner informix are all procedures.
    What we can do?

    In the 10.1.0.4 version of the workbench we create an informix user who will have all the stored procedures.
    If you want these migrated as another user you can right click on the user in the oracle model and rename it for a start.
    If this is a large migration, I would recommend the following.
    1. generate the ddl for the oracle database.
    2. for the users, that will be created, move the objects to the users that you want these in.
    3. Make sure that the privileges that a particular user has is appropriate to use the data and execute the stored procedures if necessary.
    This tool is not just a one shot deal.. It will bring the informix db over to Oracle, but you need to verify the structure and the logic of the stored procedures as being correct.
    Barry

  • How do I map Hitachi SAN LUNs to Solaris 10 and Oracle 10g ASM?

    Hi all,
    I am working on an Oracle 10g RAC and ASM installation with Sun E6900 servers attached to a Hitachi SAN for shared storage with Sun Solaris 10 as the server OS. We are using Oracle 10g Release 2 (10.2.0.3) RAC clusterware
    for the clustering software and raw devices for shared storage and Veritas VxFs 4.1 filesystem.
    My question is this:
    How do I map the raw devices and LUNs on the Hitachi SAN to Solaris 10 OS and Oracle 10g RAC ASM?
    I am aware that with an Oracle 10g RAC and ASM instance, one needs to configure the ASM instance initialization parameter file to set the asm_diskstring setting to recognize the LUNs that are presented to the host.
    I know that Sun Solaris 10 uses /dev/rdsk/CwTxDySz naming convention at the OS level for disks. However, how would I map this to Oracle 10g ASM settings?
    I cannot find this critical piece of information ANYWHERE!!!!
    Thanks for your help!

    Yes that is correct however due to use of Solaris 10 MPxIO multipathing software that we are using with the Hitachi SAN it does present an extra layer of complexity and issues with ASM configuration. Which means that ASM may get confused when it attempts to find the new LUNs from the Hitachi SAN at the Solaris OS level. Oracle Metalink note 396015.1 states this issue.
    So my question is this: how to configure the ASM instance initialization parameter asm_diskstring to recognize the new Hitachi LUNs presented to the Solaris 10 host?
    Lets say that I have the following new LUNs:
    /dev/rdsk/c7t1d1s6
    /dev/rdsk/c7t1d2s6
    /dev/rdsk/c7t1d3s6
    /dev/rdsk/c7t1d4s6
    Would I set the ASM initialization parameter for asm_diskstring to /dev/rdsk/c7t1d*s6
    as correct setting so that the ASM instance recognizes my new Hitachi LUNs? Solaris needs to map these LUNs using pseudo devices in the Solaris OS for ASM to recognize the new disks.
    How would I set this up in Solaris 10 with Sun multipathing (MPxIO) and Oracle 10g RAC ASM?
    I want to get this right to avoid the dreaded ORA-15072 errors when creating a diskgroup with external redundancy for the Oracle 10g RAC ASM installation process.

  • Installing ABAP 6.40 SR 1 on Oracle 10g

    Good Day,
    I will like to install SAP 4.7 Enterprise using kernel 6.40 on Oracle 10g. I have successfuly gone to Oracle 10g via the upgrade process by 
    a) Installing Oracle 9.2.x upto patchset 9.2.0.7
    b) Then upgrade to Oracle 10g patchset 10.2.0.2
    I have already downloaded Oracle 10g DVD's (five of them)
    Our production system is Oracle 10g, I will like to refresh QAS to Oracle 10g, so I am just enquring whether a direct install to Oracle 10g is possible, and then perfrom a restore.
    If it is possible, please direct me to the CORRECT installing guide and DVD's.
    Thanks,
    Regards,
    VKM...

    > a) I want to build my QAS server from scratch with Oracle 10g installation. The version of SAP is 4.7 Enterprise  Ext 110, with 6.40 kernel.
    For this you either need
    - an Oracle 9.2.0 client (949116 - Oracle 10g Support on Windows: 6.40-Based SAP Systems)
    - or exchange during the database creation the kernel 6.40 with 6.40_EX2 so you don't need the 9.2 client but you use the 10.2 client.
    > After this then I want to restore from production which is already Oracle 10g.
    Why first installing the system and then restoring? This can be done in one step with the system copy procedure.
    >  b) The DVD I am using is Master "Installation_Master_6.20_6.40_07_07"
    I would recommend downloading the newest installation Master CD.
    > c) During the installation under section "Database Server and Client"
    >
    > The option to choose is available for Server "102 or 920", but only "920" appears for Client.
    Yes - because at that time there was no kernel which uses the Oracle 10.2 client. That is desribed in above note.
    > When I reach the screen that asks for

    > "RDBMS Client Oracle 920"  it is looking for a label
    > ORACLE:9.2.0.7:CLRDBMS:. which I don't have and can't seem to find on "SAP Service Market place".
    >
    > N.B All the software (SAP & Oracle) for the installation was downloaded from ServiceMarketPlace
    See above
    Markus

Maybe you are looking for

  • Can't copy iPhoto Library file

    I am trying to copy my iPhoto library from one mac to another. I have them connected with an Ethernet cable. The library is about 90 GB. When I drag the library file over it appears to copy about 1/5 of the file (judging by the blue line) and then it

  • Why does adobe bridge come on when I plug in my phone?

    when i plug my phone or ipod touch into the computer sync cable the photo downloader comes on (this i like) but also adobe bridge. How can I make it not do that?thanks kt

  • Exchange has been enabled for over a year and I ST...

    Hey Everybody, I've been reading several threads and came across this one; http://community.bt.com/t5/BT-Infinity/FTTC-Exchange-and-Cabinet-BT-Wholesale/td-p/181321 Unfortunately it appears that they've pulled this from public view so I can't access.

  • I have had trim enabled but it seems for better security Apple want it turned off in Yosemite

    Hi I have a Macbook pro Early 2011 with 8gb of ram and a 126gb ssd and I have just upgraded to Yosemite. The first login to Yosemite I got a message saying Tim enabler was not active & then I realised that my version did not run on the latest version

  • INDEX GETTING UNUSABLE

    Hello everybody, I'm using Oracle 9i and I'm getting below error when I execute a anonymous block which runs through the cursor and updates the table. ORA-01502: index 'ASAP.PK_STATUS_NO' or partition of such index is in unusable state select query o