Hi

I notice when I do a backup on a database with the following

begin
declare vDest varchar (240);
declare vDay varchar (20);
set vDay = convert (char (1), datepart (weekday, current date)) ||
datename (weekday, current date); set vDest = 'C:\\Backup\\' || vDay;
VALIDATE DATABASE; BACKUP DATABASE DIRECTORY vDest TRANSACTION LOG
RENAME; end

I get log files in the same directory as the database.


i.e. 090902AA.txt for yesterday, 090903AA.txt for today


Is there any neat way of disposing of these files, we might want to
keep just the current days log file.........we don't want one every
day.

Also I notice when I open one of these log files, it contains
undisplayable characters in notepad....don't know why

When you use TRANSACTION LOG RENAME, it does two things:

1. copies the current transaction log to the backup directory
2. renames the current transaction log and saves it to the current directory

Roshintosh wrote:

On 3 Sep, 16:39, "Kory Hodgson (Sybase iAnywhere)"
<khodgson (AT) A_SPAM_FREE_sybase (DOT) com> wrote:

we could just take out the TRANSACTION LOG RENAME i suppose.

why would anyone want to rename the transaction log, is there a
benefit in doing so. Is there a logical reason why someone would want
to rename it ? I'm asking dumb questions here.....I know

We got the code from Sybase for doing our backup---

Usually this is used when the database is part of a replicating
environment. This way the old transaction logs are still available for
replication.

Roshintosh wrote:

Yes its a replicating environment.

If we take out TRANSACTION LOG RENAME, what negative consequences
could it have ?
Old transaction logs would not be available for replication, should we
keep old transaction logs indefinitely then ?

If we take out TRANSACTION LOG RENAME, would some transaction logs be
lost, surely they would still be part of the main log file ?


On 3 Sep, 22:02, "Kory Hodgson (Sybase iAnywhere)"
<khodgson (AT) A_SPAM_FREE_sybase (DOT) com> wrote:

As long as you don't truncate the transaction log instead it will be
fine. The rename allows you to break up the transaction log in smaller
chunks. Then once the data from the old logs has been synchronized they
can be removed.

Roshintosh wrote:

Roshintosh wrote:
I would NOT suggest that you go playing around with the BACKUP command
that was setup by someone else in your replicating environment until you
understand how SQL Remote (or maybe the MobiLink Client, dbmlsync) uses
old transaction logs, and you also understand what your backup and
recovery strategy is on this machine.

Here's a link to a white paper and a technical document that discusses
these two issues.

http://www.sybase.com/files/White_Pa..._070307-wp.pdf
http://www.sybase.com/detail?id=1012988

Executive overview : The 090903AA.log file that is created in the same
directory as your database file (and the active transaction log) is
typically meant to be used by SQL Remote/MobiLink Client to determine
what operations need to replicated/synchronized. The 090903AA.log that
is placed in C:\\Backup\\ directory is meant to be used in case you need
to recover your database.

Aside : Is you main database also on the C: drive? Having the backup of
your database and transaction logs on the same physical device as the
actual database and transaction log doesn't help you much if your C:
drive gets corrupted.


I would not suggest that you go playing around with the BACKUP command
that was setup by someone else in your replicating environment until you
understand how SQL Remote (or maybe the MobiLink Client, dbmlsync) uses
old transaction logs, and you also understand what your back up and
recovery strategy is on this machine. Yes, I did mean to say this again.

If you remove the TRANSACTION LOG RENAME, then your transaction log will
continue to grow indefinitely. The transaction log is binary
representation of the operations that have been executed against your
database. SQL Remote and the MobiLink Client scan this log to determine
what changes need to be replicated/synchronized.

Renamed transaction logs ARE available for replication. By default,
transaction logs found in the same directory as the active transaction
log can be found by SQL Remote and the MobiLink Client.

You can also set a database option called delete_old_logs to delete
renamed transaction logs once SQL Remote or the MobiLink Client
determine that they are no longer needed. This is explained in the
technical document I provided a link to at the top of this post.


I would not suggest that you go playing around with the BACKUP command
that was setup by someone else in your replicating environment until you
understand how SQL Remote (or maybe the MobiLink Client, dbmlsync) uses
old transaction logs, and you also understand what your back up and
recovery strategy is on this machine. Yes, I really did mean to say
this a third time.

No, you would not lose any transaction logs, but you would end up with a
single large transaction log. Every time you started SQL Remote or the
MobiLink Client, the process would need to scan over all the entire
transaction log to get to the latest operations that occurred.


--
Reg Domaratzki, Sybase iAnywhere Solutions
Please reply only to the newsgroup

Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere
-> Optionally set filter to "Display ALL platforms IN ALL MONTHS"

Roshintosh wrote:
I should also have stressed in my last post that your should NOT delete
the renamed transaction logs in the same directory as the database file.
These are needed for replication/synchronization and you have the
potential to destroy your ability to replicate/synchronize data if you
start deleting these files.

--
Reg Domaratzki, Sybase iAnywhere Solutions
Please reply only to the newsgroup

Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere
-> Optionally set filter to "Display ALL platforms IN ALL MONTHS"