When I switched from Firebird to Sybase I noticed that all of my databases suddenly had a corresponding .log file. One of my tables with a media field was over 50MB in size and its .log file was also over 50MB.
I just discovered how to change a Sybase database file so it will not require a corresponding .log file. The steps are as follows:
make sure the database file is not running
open Sybase Central
double-click “Adaptive Server Anywhere 9” on the left
click the “Utilities” tab on the right
double-click “Change Log File Settings” to run the Wizard
Some of you may have already known this. If not, I hope this helps.
Please note that if you run the database without a log you don’t have any transactions. I wouldn’t recommend using it in production to avoid potential loss of data.
jaleman:
Please note that if you run the database without a log you don’t have any transactions. I wouldn’t recommend using it in production to avoid potential loss of data.
Could you explain this a little more? For example, how would this differ from using a Firebird or FileMaker database without a log file?
First of all let me point out that Firebird does have a transaction log but stores this in the same file as the database file, additionally it automatically cleans it up once in a while.
Not using transactions (like Filemaker, or if you disable it in Sybase) can potentially be dangerous. For example: when your machine or database crashes the database could be in writing data to the file thus leaving it in an inconsistent or corrupted state.
A second benefit of transactions (when you use them inside Servoy with the Database Manager) is that fact that you can undo actions. For example in Servoy you can do:
-Begin Transaction
-Delete 100,000 rows, insert 200,000 rows and change 50 rows
when done you can first check if all went allright, if it didn’t you can undo this entire transaction with one command or you can commit the transaction if everything is correct. This is one of the biggest benefits of transactional database.
Thinking about this some more. Would it be correct to say that in order for us to take advantage of the transaction benefits of a Sybase .log file our solution must include the databaseManager startTransaction, commitTransaction, and rollbackTransaction methods?
Yes and no.
For the transactionlog that protects you from crashes you don’t have to use transactions. If you want to be able to undo actions you need to use transactions in Servoy.
I went back and re-established a log file for each of our databases. I was pleased to see that each .log file starts out at only 128kb in size. This really solves my problem. The database I have with a media field that is over 50MB in size with a 50MB .log file, now has a log file that is only 128kb. This makes it much easier to download.
Not using a logfile has nothing to do with the ability to do transactions in Sybase. All it means is you don’t really care if your database never needs to be recovered from a failure, that you can start over with a blank or template database.
ve3cnu:
Not using a logfile has nothing to do with the ability to do transactions in Sybase. All it means is you don’t really care if your database never needs to be recovered from a failure, that you can start over with a blank or template database.
You sound like an expert on this topic! Would you care to explain this a bit more in detail? All I learned from the documentation that comes with ASA is that the .log file contains the transactions and that they don’t exist without it.
Hi,
I guess I am an expert as I work for Sybase tech support, but I’m not here to makes claims to that effect. I just wanted the truth out here.
You are correct the transaction log contains all the transactions that are applied to the db. But the db file also contains this information every time a checkpoint occurs. So why a seperate file for redundant data? In case one fails of course! Also the data in the transaction log is recorded in a serial form whereas the db file is based on loosely structured pages. Using a transaction log is also much faster in performance than not using one.
The transaction log is a separate file from the database file. It stores all changes to the database. Inserts, updates, deletes, commits, rollbacks, and database schema changes are all logged. The transaction log is also called the forward log or the redo log.
The transaction log is a key component of backup and recovery, and is also essential for data replication using SQL Remote or the Replication Agent.
By default, all databases use transaction logs. Using a transaction log is optional, but you should always use a transaction log unless you have a specific reason not to. Running a database with a transaction log provides much greater protection against failure, better performance, and the ability to replicate data.
