ORA-01000: maximum open cursors exceeded

"is ... this error... caused [by] missing or bad data generation from program?"
No.
This error is caused by programs that do not close cursors after they open them, or by a program design that opens many cursors in Oracle before closing the database session.

You may be able to avoid this error by increasing your value for OPEN_CURSORS.  Run this query to see what value your system has now:
select value from v$parameter where name = 'open_cursors';

Please post the result of that query here.  Also please tell us if this is a new system or a new error in a system that has been working for some time.  Or, was a change made recently in the system or in this applciation?

Value is 300.

And my question was my question, the program completes after generating these errors and I want to know if the error (exceeded cursors) caused us to lose any data that was being loaded?  My guess is yes but I'm asking.

You shouldn't lose any data. Data that was already pointed by the current open cursors should not be lost. New data cannot be accessed though.

True, for data that was already saved, this error will not cause any data loss.  But in a data load procedure that we know nothing about, the answer is not so clear.

How many records should be loaded?  Does the load procedure commit after each record, or incrementally after each 10 or 100 or some other interval?  Or does it commit only at the end?  It is possible that this error could cause some records to not be loaded that were intended to be loaded.

Knowing how many records should be loaded is difficult to know since it is reading and parsing xml from a  column in a sql server table. I do know not all key items I was able to query In the xml are making it over. Sounds like from both answers that the open cursors at the time of the errors will write but remaining data will not be processed?

"remaining data will not be processed"
True, that is easy to answer.

"open cursors at the time of the errors will write"
Maybe

It depends on how the dataload program is written: mainly on exactly when it does commits.  We have no information on that.

I will look at the code to determine when it commits. one thing I did notice while monitoring the session in Toad was that only one SID and query was running.

"while monitoring the session in Toad …"
Are you sure that gives you the whole picture?  Are you sure that Toad does not have multiple database sessions open?  Do you have OEM (Oracle Enterprise Monitor) or some other whole-system monitor that can give you a complete picture of what's going on in the database at the time?

OPEN_CURSORS is a session level variable.  Each session has its own pool of cursors that is limited by the parameter.  It is not a system wide parameter.  If you are monitoring with a tool, it would not affect the running processes number of cursors.

The issue is an application issue.  It is definitely not closing cursors.  It is likely reusing the same cursor without closing it.  In a loop, you can define the cursor outside the loop and then use it repeatedly within the loop by binding it properly.  Declaring it each time in the loop, leads to this issue.

The issue was occurring when the program read very large notes in an xml node. I increased the number of processes from 1 to 3 and that error went away, and at the same time, a lot more data was imported...however, now I am seeing this message...

java.sql.SQLRecoverableException: Closed Connection repeatedly

I looked at how the code is closing the cursors and I do not see where it is leaving the cursor open. Could it be that some value in the notes tag is being interpreted incorrectly causing other cursors to open?

why would increasing the processors (threads) stop the open cursor issue but now indicate a closed connection issue?

"why would increasing the process[es] (threads) stop the open cursor issue?"  (I think you intended "processes" there, not processors.)
With multiple processes, the work load can be split up among multiple database sessions.  The error you were hitting was a per-process limit.  Now with multiple processes to divide the work, maybe none of them are getting to the limit of 300 cursors in a single session (process).

I'm not a Java expert so maybe someone else will help you on your latest error.  It does sound possible to me that a "data-related problem" could be caused by a particular character, or combination of characters in the data being processed.

so interesting. I increased the processes to 6 and no more issues.

I agree. I am curious also. when I get some time I will see how that is being managed.

thank you all for your superb guidance.

thank you for the help!!!

Increasing the number of processes doesn't fix the problem.  You still have an issue that needs to be fixed.  You should not be opening cursors uncontrollably like that.

thanks for the comment. we are testing. there may not be a problem and the open cursors May be due to the 300 limit.

I agree that a limit of 300 may be too low for "open_cursors".  We have that set to 500, 600 or 1,000 in three of our busiest systems.

I don't see where a single process needs 1,000 concurrent open cursors.  Increasing the parameter in most cases is just delaying the problem.  In the vast majority of cases, the issue is cursor management in the application.  You shouldn't be changing the parameters of the database due to a deficiency in the application, that is just asking for trouble.

yes, in our environment due to heavy traffic outside, the dba’s won’t increase over 300.

Johnson, in our case, this is a one time load. no reason to spend time rewriting something that is only needed one time.

And as an admin, I have had to baby sit horrid code for hours because developers were too lazy to write it correctly the first time.  One time or not, there is no excuse for code like this.  If it were my system, you wouldn't be allowed to run it.  One time or not.

I’d agree if this were in production.