SQL Anywhere Feedback - dbTran Additional Options

Author

dbTran Additional Options

Jim Diaz

2006-01-04, 1:23 pm

Two additional dbTran options would be nice

1) Maximum output file size
When translating a large log file the SQL file can be very large. The
file should end after a complete transaction only.

2)Validate Log File Only
I do this now by specifying -it dba.bogus a table that doesn't exist
however an option would be nice.

Thanks

Jim

Nick Elson

2006-01-06, 11:23 am

For the second one I usually just use

dbtran -y _x_x_x_.log nul: [on Windows*]
or
dbtran -y _x_x_x_.log /dev/nul [on UNIX*]

I would be concerned with your first sugggestion, since it
could leave the wrong impression. That is, it would always
produce an apparently valid result which is probably
incomplete. I would definitely like some feedback
about when it is complete verses truncated.

On a related point, people (ok, me) have used the -ir to
explicitly control ranges and thus sizes. Not as easy but
something that makes this kind of thing possible today. To
find useful -ir values a single pass with dbtran -f helps a lot.

"Jim Diaz" < jimdiazatemprisecorp
orationdotcom> wrote in message
news:43bc1a0f$1@foru
ms-2-dub...
> Two additional dbTran options would be nice
>
> 1) Maximum output file size
> When translating a large log file the SQL file can be very large. The
> file should end after a complete transaction only.
>
> 2)Validate Log File Only
> I do this now by specifying -it dba.bogus a table that doesn't exist
> however an option would be nice.
>
> Thanks
>
> Jim
>

Jim Diaz

2006-01-07, 8:23 pm

Nick:

I love the -y :null trick, that must be why you make the big bucks....

Let me explain a little more about the file size thing. The other day I
translated 2,148 database log files looking for changes made to a single
table. This resulted in sql files from 0 to 1.6 GB in size. From this
point I grepped the files looking for certain key inserts. The large files
were a bit of a pain to look at in an editor. How often do I do this? Once
so far, but that was enough of a pain to induce me to ask for the mod....
:-)

Thanks

Jim

"Nick Elson" < no_span_nicelson@syb
ase.com> wrote in message
news:43be95ac$1@foru
ms-2-dub...
> For the second one I usually just use
>
> dbtran -y _x_x_x_.log nul: [on Windows*]
> or
> dbtran -y _x_x_x_.log /dev/nul [on UNIX*]
>
> I would be concerned with your first sugggestion, since it
> could leave the wrong impression. That is, it would always
> produce an apparently valid result which is probably
> incomplete. I would definitely like some feedback
> about when it is complete verses truncated.
>
> On a related point, people (ok, me) have used the -ir to
> explicitly control ranges and thus sizes. Not as easy but
> something that makes this kind of thing possible today. To
> find useful -ir values a single pass with dbtran -f helps a lot.
>
>
>
> "Jim Diaz" < jimdiazatemprisecorp
orationdotcom> wrote in message
> news:43bc1a0f$1@foru
ms-2-dub...
>
>

Nick Elson

2006-01-09, 11:23 am

GREP is my friend too ... but I have often considered writing a
more customized tool for this kind of work; but usually something
else allows me to avoid doing that.

> . . . The other day I translated 2,148 database log files looking for
> changes made to a single table. . . .

Definitely a case for the "-it table" switch. Unless the
table in question attracts the majority of operations then
this alone could significantly reduce the size of the output.

If you also happened to know which user accounts
may/may not have been able to have made the change
then
-uuser,...
or
-xuser
(respectively) may also have helped reduce these volumes
down.

Further ... on the subject of the number of files involved ... If the log
files were consecutive (as in due to dbbackup -r) then the "-m <dir>"
switch could have been of some assistance in executing *just 1 command*
to produce *just 1 output file* [assuming the above 2 observations
could reduce the total size down to something managible. Not a
reduction of size thing, but a possible reduction in the number of steps.

When replication or synchronisation is involved you may also
partion/filter the operations by their source using the -is switch.

I am not certain if any of this will address your specific situation
but they can really help from my experience.

"Jim Diaz" < jimdiazatemprisecorp
orationdotcom> wrote in message
news:43c0342c$1@foru
ms-2-dub...
> Nick:
>
> I love the -y :null trick, that must be why you make the big bucks....
>
> Let me explain a little more about the file size thing. The other day I
> translated 2,148 database log files looking for changes made to a single
> table. This resulted in sql files from 0 to 1.6 GB in size. From this
> point I grepped the files looking for certain key inserts. The large files
> were a bit of a pain to look at in an editor. How often do I do this?
> Once so far, but that was enough of a pain to induce me to ask for the
> mod.... :-)
>
> Thanks
>
> Jim
>
>
> "Nick Elson" < no_span_nicelson@syb
ase.com> wrote in message
> news:43be95ac$1@foru
ms-2-dub...
>
>

Breck Carter [TeamSybase]

2006-01-09, 1:23 pm

On 9 Jan 2006 08:36:11 -0800, "Nick Elson"
< no_span_nicelson@syb
ase.com> wrote:

>something else allows me to avoid doing that

True mastery of Work Avoidance comes with experience :)

Breck

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com

Sponsored Links