Re: [sqlite] Query on database back-up:

2013-08-02 Thread techi eth
Thanks.All cases clear except below

What happen if other process is not able to complete operation within
timeout duration?

Cheers -
Techi




On Fri, Aug 2, 2013 at 2:28 PM, Clemens Ladisch  wrote:

> > techi eth wrote:
> >> 1. "Any database clients wishing to write to the database file while a
> >> backup is being created must wait until the shared lock is
> >> relinquished."
> >
> > Example 1: Loading and Saving In-Memory Databases will not fulfill
> > this shortcoming.
>
> In-memory databases cannot be accessed by other clients.
>
> > Example 2: Fulfill the shortcoming but cost of more time due to
> > restart of backup from fresh in the case of INSERT, ALTER, DROP &
> > UPDATE.
> >
> > Addinitionally what happen if other process is not able to complete
> > operation within timeout duration?
>
> If you tell the backup API to copy all pages at once, you get
> a behaviour similar to a plain file copy.  Using smaller steps allows
> you to balance the speed of the backup itself against the risk of other
> clients being locked out for too long.
>
> >> 2. "It cannot be used to copy data to or from in-memory databases."
> >
> > I haven't got it full but I understand by CP I am able to copy any
> > file in Linux system.
>
> And an in-memory database does not have a file.
>
> >> 3."If a power failure or operating system failure occurs while copying
> >> the database file the backup database may be corrupted following
> >> system recovery"
> >
> > This is very useful benefit. What is the resulted outcome of power
> > failure or OS failure if we use backup API?
>
> The transaction is rolled back, and the destination is not changed.
>
>
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Query on database back-up:

2013-08-02 Thread Clemens Ladisch
> techi eth wrote:
>> 1. "Any database clients wishing to write to the database file while a
>> backup is being created must wait until the shared lock is
>> relinquished."
>
> Example 1: Loading and Saving In-Memory Databases will not fulfill
> this shortcoming.

In-memory databases cannot be accessed by other clients.

> Example 2: Fulfill the shortcoming but cost of more time due to
> restart of backup from fresh in the case of INSERT, ALTER, DROP &
> UPDATE.
>
> Addinitionally what happen if other process is not able to complete
> operation within timeout duration?

If you tell the backup API to copy all pages at once, you get
a behaviour similar to a plain file copy.  Using smaller steps allows
you to balance the speed of the backup itself against the risk of other
clients being locked out for too long.

>> 2. "It cannot be used to copy data to or from in-memory databases."
>
> I haven't got it full but I understand by CP I am able to copy any
> file in Linux system.

And an in-memory database does not have a file.

>> 3."If a power failure or operating system failure occurs while copying
>> the database file the backup database may be corrupted following
>> system recovery"
>
> This is very useful benefit. What is the resulted outcome of power
> failure or OS failure if we use backup API?

The transaction is rolled back, and the destination is not changed.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Query on database back-up:

2013-08-02 Thread techi eth
Appreciate if I will get clarification.

If any of the point out of the scope of mailing list then please mark.
Thanks a lot!!!


On Wed, Jul 31, 2013 at 6:53 PM, techi eth  wrote:

> Thanks for answer.
>
> Let me put my query on point mentioned by comparing historic way of
> doing copy at the start of link.
> 1. "Any database clients wishing to write to the database file while a
> backup is being created must wait until the shared lock is
> relinquished."
>
> Example 1: Loading and Saving In-Memory Databases will not fulfill
> this shortcoming.
>
> Example 2: Fulfill the shortcoming but cost of more time due to
> restart of backup from fresh in the case of INSERT, ALTER, DROP &
> UPDATE.I understand SELECT will not add time.
>
> Addinitionally what happen if other process is not able to complete
> operation within timeout duration?
>
> 2. "It cannot be used to copy data to or from in-memory databases."
>
> I haven't got it full but I understand by CP I am able to copy any
> file in Linux system.
>
> 3."If a power failure or operating system failure occurs while copying
> the database file the backup database may be corrupted following
> system recovery"
>
> This is very useful benefit. What is the resulted outcome of power
> failure or OS failure if we use backup API?
>
>
>
> On 7/31/13, Simon Slavin  wrote:
> >
> > On 31 Jul 2013, at 12:56pm, techi eth  wrote:
> >
> >> I have followed below link for details. It say “If another thread or
> >> process writes to the source database while this function is sleeping,
> >> then
> >> SQLite detects this and usually restarts the backup process when
> >> sqlite3_backup_step() is next called”.
> >>
> >> - It means it will start back-up from start or resume from last left
> page
> >> but making sure all update will be written in backup file.
> >
> > Every time a change is made the backup has to restart from the beginning
> > again.  So if, for example, it would take 300 seconds to backup the
> entire
> > file, the backup process will not complete until there has been a 300
> second
> > period when no changes were made to the file.
> >
> >> - Is their any issue if process acquiring database handle will do both
> >> the
> >> operation (Writing & Backup).
> >
> > No.  This is not a problem.  Though, of course, if anything does use that
> > handle to write to the database the backup will be (automatically)
> > restarted.
> >
> >> http://www.sqlite.org/backup.html
> >
> > Simon.
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Query on database back-up:

2013-07-31 Thread Dan Kennedy

On 07/31/2013 07:33 PM, Simon Slavin wrote:

On 31 Jul 2013, at 12:56pm, techi eth  wrote:


I have followed below link for details. It say “If another thread or
process writes to the source database while this function is sleeping, then
SQLite detects this and usually restarts the backup process when
sqlite3_backup_step() is next called”.

- It means it will start back-up from start or resume from last left page
but making sure all update will be written in backup file.

Every time a change is made the backup has to restart from the beginning again. 
 So if, for example, it would take 300 seconds to backup the entire file, the 
backup process will not complete until there has been a 300 second period when 
no changes were made to the file.


- Is their any issue if process acquiring database handle will do both the
operation (Writing & Backup).

No.  This is not a problem.  Though, of course, if anything does use that 
handle to write to the database the backup will be (automatically) restarted.


Actually this is an exception to that rule. If a connection
being used as the source in a backup operation writes to
the database, the backup does not have to be restarted. Instead,
the backup db is modified at the same time to keep it up to
date with the source db.

Dan.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Query on database back-up:

2013-07-31 Thread techi eth
Thanks for answer.

Let me put my query on point mentioned by comparing historic way of
doing copy at the start of link.
1. "Any database clients wishing to write to the database file while a
backup is being created must wait until the shared lock is
relinquished."

Example 1: Loading and Saving In-Memory Databases will not fulfill
this shortcoming.

Example 2: Fulfill the shortcoming but cost of more time due to
restart of backup from fresh in the case of INSERT, ALTER, DROP &
UPDATE.I understand SELECT will not add time.

Addinitionally what happen if other process is not able to complete
operation within timeout duration?

2. "It cannot be used to copy data to or from in-memory databases."

I haven't got it full but I understand by CP I am able to copy any
file in Linux system.

3."If a power failure or operating system failure occurs while copying
the database file the backup database may be corrupted following
system recovery"

This is very useful benefit. What is the resulted outcome of power
failure or OS failure if we use backup API?



On 7/31/13, Simon Slavin  wrote:
>
> On 31 Jul 2013, at 12:56pm, techi eth  wrote:
>
>> I have followed below link for details. It say “If another thread or
>> process writes to the source database while this function is sleeping,
>> then
>> SQLite detects this and usually restarts the backup process when
>> sqlite3_backup_step() is next called”.
>>
>> - It means it will start back-up from start or resume from last left page
>> but making sure all update will be written in backup file.
>
> Every time a change is made the backup has to restart from the beginning
> again.  So if, for example, it would take 300 seconds to backup the entire
> file, the backup process will not complete until there has been a 300 second
> period when no changes were made to the file.
>
>> - Is their any issue if process acquiring database handle will do both
>> the
>> operation (Writing & Backup).
>
> No.  This is not a problem.  Though, of course, if anything does use that
> handle to write to the database the backup will be (automatically)
> restarted.
>
>> http://www.sqlite.org/backup.html
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Query on database back-up:

2013-07-31 Thread Simon Slavin

On 31 Jul 2013, at 12:56pm, techi eth  wrote:

> I have followed below link for details. It say “If another thread or
> process writes to the source database while this function is sleeping, then
> SQLite detects this and usually restarts the backup process when
> sqlite3_backup_step() is next called”.
> 
> - It means it will start back-up from start or resume from last left page
> but making sure all update will be written in backup file.

Every time a change is made the backup has to restart from the beginning again. 
 So if, for example, it would take 300 seconds to backup the entire file, the 
backup process will not complete until there has been a 300 second period when 
no changes were made to the file.

> - Is their any issue if process acquiring database handle will do both the
> operation (Writing & Backup).

No.  This is not a problem.  Though, of course, if anything does use that 
handle to write to the database the backup will be (automatically) restarted.

> http://www.sqlite.org/backup.html

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users