There are a lot of the following errors in the log:
14:05:58.827 ERROR: DISCARD ALL cannot be executed inside a transaction block
14:05:58.827 OPERATOR: DISCARD ALL
14:05:58.827 ERROR: current transaction is aborted, commands ignored until end of transaction block
14:05:58.827 OPERATOR: BEGIN
14:05:58.827 ERROR: current transaction is aborted, commands ignored until end of transaction block
14:05:58.827 OPERATOR: SET TRANSACTION ISOLATION LEVEL READ COMMITTED
14:05:58.827 ERROR: current transaction is aborted, commands ignored until end of transaction block
In the application that worked with this database, some functionality did not work partially. All this went on for half an hour. There are no direct calls to "DISCARD ALL", "BEGIN", or "SET TRANSACTION ISOLATION LEVEL READ COMMITTED" in the code. Access to the server is closed, there is only a log. Trying to figure out what it was, have any ideas?
It looks like you have a broken connection pooler. All of those commands could be issued by a connection pooler automatically when they check connections in or out. So a seems like connection got broken, but the pooler blithely kept trying to hand it out anyway. On the other hand, once it does hand out the connection something should happen on it which would cause yet more log messages, which doesn't seem to be happening, so maybe it keeps trying to 'revive' the connection, unsuccessfully.
But access to the server is not closed. Many of those errors are coming from the server, so there must still be a connection to the server. (You put "the connection was dropped by the other side" in the title, but that phrase is not included in any of the log you showed us so I don't know where you are getting it from.) But the connection is in an aborted transaction, and is waiting for you to issue a rollback; or a commit; before it becomes usable again.
Related
when i try to logon bteq, i get the following error,
*** Warning: RDBMS CRASHED OR SESSIONS RESET. RECOVERY IN PROGRESS.
and then i try to restart the database,
pdestate -a
status:
PDE state: DOWN/HARDSTOP
start:
/etc/init.d/tpa start
result:
Teradata Database Initiator service is starting...
Teradata Database Initiator service started successfully.
then check the status again:
PDE state: DOWN/HARDSTOP
i tried many times, but still can not start database, don't know the reason,
From the "Messages" manual:
Remove file
13821 Crash loop detected during TPA initialization. Explanation: In order to prevent PDE initialization from looping forever when an error prevents it from completing, it is only automatically restarted three times. After three unsuccessful initialization attempts, this message is issued and restart attempts are discontinued, leaving PDE down.
rm /var/opt/teradata/tdtemp/PanicLoopDetected
To start Teradata DBMS use
/etc/init.d/tpa start
To confirm that the database has come up, type
pdestate -a
After giving the command, wait a minute or so and give the same command again. Keep trying. After a few trails (minutes), the database will be started. Looks weird, but works :- )
On the linux server, where our web app runs, we also have a small app that uses
sqlite (it is written in c).
For performing database actions we use the following commands:
sqlite3_prepare_v2
sqlite3_bind_text or sqlite3_bind_int
sqlite3_step
sqlite3_finalize
Every now and then there was a concurrency situation and I got the following error:
database is locked
So I thought: "This happens when one process writes a certain record and the
other one is trying to read exactly the same record."
So after every step-command, where this collision could be, I checked for this error. When it happended, I waited a few milliseconds and the tried again.
But the sqlite error "database is locked" still occurred.
So I changed every step command and the code lines after it. Somehow I thought that this "database is locked" error could only occur with the step command.
But the error kept coming.
My question is now:
Do I have to check after any sqlite3 command for "error_code ==5" (database is locked)?
Thanks alot in advance
If you're receiving error code 5 (busy) you can limit this by using an immediate transaction. If you're able to begin an immediate transaction, SQLite guarantees that you won't receive a busy error until you commit.
Also note that SQLite doesn't have row-level locking. The entire database is locked. Using a WAL journal, you can one writer and multiple readers. With other journaling methods, you can have either one writer, or multiple readers, but not both simultaneously.
SQLite Documentation on 'SQLITE_BUSY'
My scenario is simple, I have one process generating some data and putting it into the database (currently 5 seconds after the last one is finished) and then there are any number of processes opening a connection to read a single record to use internally (currently 5 seconds after the last one is finished). The database is located on the local drive and the OS is Windows Server 2012 R2.
With the reader processes I am occasionally receiving an error when connecting to the sqlite database, when the connection is opened an [FireDAC][Phys][SQLite] ERROR: unable to close due to unfinalized statements or unfinished backups exception is thrown and I'm stumped on the cause and the meaning of the error message (in the case of opening a connection).
My connection is created like so (in both the reader and writer application):
connection := TFDConnection.Create(nil);
connection.Params.Add('DriverID=SQLite');
connection.Params.Add('Database=' + aDatabasePath);
connection.Params.Add('OpenMode=CreateUTF16');
connection.Params.Add('LockingMode=Normal');
connection.Params.Add('JournalMode=WAL');
connection.Params.Add('Synchronous=Full');
connection.Params.Add('UpdateOptions.LockWait=True');
connection.Params.Add('BusyTimeout=30000');
connection.Params.Add('SQLiteAdvanced=temp_store=MEMORY');
connection.Params.Add('SQLiteAdvanced=page_size=4096');
connection.Params.Add('SQLiteAdvanced=auto_vacuum=FULL');
connection.Open();
After investigating the EFDDBEngineException that gets thrown there is only a single error in the list of errors and it contains ErrorCode=5 which sqlite errorcodes and sqlite result codes say are the SQLITE_BUSY error.
Investigating the callstack
ntdll.dll KiUserExceptionDispatcher
FireDAC.Phys.SQLite TFDPhysSQLiteConnection.InternalDisconnect
FireDAC.Phys TFDPhysConnection.ConnectBase
ntdll.dll KiUserExceptionDispatcher
FireDAC.Phys.SQLiteWrapper TSQLiteStatement.PrepareBase
FireDAC.Phys.SQLiteWrapper TSQLiteStatement.Prepare
FireDAC.Phys.SQLiteWrapper TSQLiteStatement.Prepare
FireDAC.Phys.SQLite TFDPhysSQLiteConnection.InternalExecuteDirect
FireDAC.Phys.SQLite SetPragma
FireDAC.Phys.SQLite TFDPhysSQLiteConnection.InternalConnect
FireDAC.Phys TFDPhysConnection.ConnectBase
FireDAC.Phys TFDPhysConnection.DoConnect
FireDAC.Phys TFDPhysConnection.Open
FireDAC.Comp.Client TFDCustomConnection.DoInternalLogin
FireDAC.Comp.Client TFDCustomConnection.DoLogin
FireDAC.Comp.Client TFDCustomConnection.DoConnect
Data.DB TCustomConnection.SetConnected
FireDAC.Comp.Client TFDCustomConnection.SetConnected
Data.DB TCustomConnection.Open
It's obviously not liking something that is happening in TSQLiteStatement.PrepareBase which then results in TFDPhysConnection.ConnectBase attempting to cleanup whatever point the creating of the connection is up to but where would the unfinalized statement be?
I Close() and Free() every TFDQuery and the connection when I'm finished.
What am I missing?
On a side note because it is a problem for me. Once the error occurs the WAL and SHM files don't get collapsed into the database file, and if I try to run the reader application on my dev machine under the debugger pointing at the database in the shared folder it locks completely when trying to open a connection and ending all other readers and the writer process doesn't unlock it and then I need to restart my dev machine.
We have a new beta version of our software with some changes, but not around our database layer.
We've just started getting Error 3128 reported in our server logs. It seems that once it happens, it happens for as long as the app is open. The part of the code where it is most apparent is where we log data every second via SQLite. We've generated 47k errors on our server this month alone.
3128 Disk I/O error occurred. Indicates that an operation could not be completed because of a disk I/O error. This can happen if the runtime is attempting to delete a temporary file and another program (such as a virus protection application) is holding a lock on the file. This can also happen if the runtime is attempting to write data to a file and the data can't be written.
I don't know what could be causing this error. Maybe an anti-virus program? Maybe our app is getting confused and writing data on top of each other? We're using async connections.
It's causing lots of issues and we're at a loss. It has happened in our older version, but maybe 100 times in a month rather than 47,000 times. Either way I'd like to make it happen "0" times.
Possible solution: Exception Message: Some kind of disk I/O error occurred
Summary: There is probably not a problem with the database but a problem creating (or deleting) the temporary file once the database is opened. AIR may have permissions to the database, but not to create or delete files in the directory.
One answer that has worked for me is to use the PRAGMA statement to set the journal_mode value to something other than DELETE. You do this by issuing a PRAGMA statement in the same way you would issue a query statement.
PRAGMA journal_mode = OFF
Unfortunately, if the application crashes in the middle of a transaction when the OFF journaling mode is set, then the database file will very likely go corrupt.1.
1 http://www.sqlite.org/pragma.html#pragma_journal_mode
The solution was to make sure database delete, update, insert only happened one at at time by wrapping a little wrapper. On top of that, we had to watch for error 3128 and retry. I think this is because we have a trigger running that could lock the database after we inserted data.
I am currently trying to get search working in my Tridion 2011 installation. I read in another article that I should run the TcmReIndex.exe tool in the Tridion/bin folder to re-index all my sites. So I tried this and it failed with a message box giving the following details
Unable to get list of Publication items.
Unable to Intialize TDSE object.
The wait operation timed out
Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=21054; handshake=35;
The wait operation timed out
A database error occurred while executing Stored Procedure "EDA_TRUSTEES_GETTRUSTEEETOKEN"
I have four fairly large publications (100 000+ items in total) which I am trying to index.
Any ideas?
Whenever I get "Unable to Intialize TDSE object." errors, I typically write a small test script using VBScript, and try running it on the CMS server. Whilst this does not directly solve the problem, it often gives some insight into the issue by logging information in the event viewer. Try creating a test.vbs file as follows and running it:
Set tdse = CreateObject("TDS.TDSE")
tdse.initialize()
msgbox(tdse.User.Description)
Set tdse = Nothing
If it throws any errors, please let me know, and it may help us solve the problem. If it gives you a popup with your user description, then I am completely barking up the wrong tree.
I haven't come to anything conclusive but it seems like my issue may have been a temporary one as it just started working. I did increase all timeouts in Tridion MMC > Timeout Settings by 100 times their amounts but I suspect that this wasn't the issue, when it works the connection is almost instant.
If anyone else has this issue
Restart the computer the content manager is installed on, try again.
Wait an hour or two, try again.
Increase timeouts, try again.
I've run the process a few more times and it seems to be working correctly.