2011-08-22 9 views
6

Mój zespół programistów doświadcza licznych błędów ORA-12571: TNS:packet writer failure przy użyciu ASP.NET 3.5 i 4.0 przeciwko Oracle 11g. Błędy te są niespójne co do ich wystąpienia i są generowane przez liczne aplikacje. Ten wyjątek występuje podczas wywoływania losowych procedur składowanych, pakietów i wbudowanych instrukcji SQL. Klient Oracle 11 jest zainstalowany na serwerze sieciowym. Niektóre aplikacje używają Microsoft System.Data.OracleClient do łączenia się z Oracle, a niektóre używają składników .NET dostarczanych przez Oracle (ODP.NET). Oba obiekty dostępu do danych mają ten sam błąd.ORA-12571: TNS: awaria programisty pakietów z ASP.NET

Istnieją inne aplikacje .NET, które działają na innym serwerze sieci Web, ale korzystają z tego samego serwera bazy danych. Aplikacje nie mają takich problemów. Wstępnie myślę, że jest coś nieprawidłowo skonfigurowanego na serwerze WWW z klientem Oracle.

Czy ktoś jeszcze otrzymał ten błąd? Co zrobiłeś, żeby to naprawić?

ORA-12571: TNS:packet writer failure 

stosu Ślad:

at System.Data.OracleClient.OracleConnection.CheckError(OciErrorHandle errorHandle, Int32 rc) 
    at System.Data.OracleClient.OracleCommand.Execute(OciStatementHandle statementHandle, CommandBehavior behavior, Boolean needRowid, OciRowidDescriptor& rowidDescriptor, ArrayList& resultParameterOrdinals) 
    at System.Data.OracleClient.OracleCommand.Execute(OciStatementHandle statementHandle, CommandBehavior behavior, ArrayList& resultParameterOrdinals) 
    at System.Data.OracleClient.OracleCommand.ExecuteReader(CommandBehavior behavior) 
    at System.Data.OracleClient.OracleCommand.ExecuteDbDataReader(CommandBehavior behavior) 
    at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) 
    at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) 
    at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) 
    at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) 

Odpowiedz

1

myślę, że jest to błąd w Oracle. Natknąłem się na wiele problemów z metodą DBDataAdapter.Fill, w której klient Oracle dusiłby się z powodu błędu pamięci. Ten problem został rozwiązany za pomocą klienta 11.2.0.2 z zainstalowanym łatką 6.

Jeśli przeszukasz witrynę pomocy technicznej Oracle, zobaczysz wiele takich problemów.

Sprawdź również problemy z "Czytaniem chronionej pamięci" w przypadku klientów 11g1/11g2.

+0

Dzięki za poradę. Spróbuję zainstalować klienta 11.2 z nałożonym łatką 6. – dretzlaff17

+0

Jestem w fazie tego samego problemu @ dretzlaff17, jeśli rozwiązałeś go, proszę wspomnieć, jak go rozwiązałeś. tj. przy wykonywaniu SP z parametrami wejścia i wyjścia im otrzymywanie błędu, jak wspomniano, to działa poprawnie. mam nadzieję, że wkrótce powrócisz do mojego komentarza. – Maxymus

5

Innym możliwym rozwiązaniem jest to, że zapora między tobą a bazą danych Oracle sądzi, że twoje połączenie jest martwe i zamyka je pod tobą. Dowiesz się tylko, kiedy spróbujesz wykonać zapytanie i uzyskasz błąd ORA-12571.

Jest to spowodowane tym, że połączenia są otwarte przez długi czas bezczynności.

Rozwiązaniem jest dodanie SQLNET.EXPIRE_TIME do pliku sqlnet.ora na serwerze i ustawienie go w pewnym przedziale (10). Spowoduje to, że połączenia będą pingowane co 10 minut, aby upewnić się, że nadal są aktywne.

Powoduje to, że zapora sieciowa zobaczy aktywność sieciową i nie zamknie połączenia.

SQLNET.EXPIRE_TIME=10 

ORA-12571: TNS:packet writer failure - One of the hardest problems I've had to resolve

+0

Link jest wyłączony :( – SuperJMN

+0

Dzięki za powiadomienie mnie, link zaktualizowany – JordanBean

0

Po zainstalowaniu modułu ELMAH i może analizować wyjątki, próbowałem:

  1. zmienić konfigurację połączenia.
  2. Usuń i/lub zaktualizuj reguły zapory serwera.
  3. Zaktualizuj klienta Oracle na komputerze serwera.

Każda z powyższych opcji rozwiązania problemu, ale ja zapominając nieaktualne dostawcy (System.Data.OracleClient) używaliśmy. Po zastąpieniu go ostatnią wersją ODP.NET (Oracle.DataAccess), wszystko zaczęło działać bezbłędnie.

Obs: W oparciu o opis wyjątku korzystasz obecnie z przestarzałego dostawcy.

Powiązane problemy