24.03.2016 11:27, Simonov Denis wrote:
> Vlad Khorsun wrote Wed, 23 Mar 2016 17:43:23
> +0300:
>
>>
>> Let me show how it works. It is very simplified example, of course.
>>
>> Create database source.fdb.
>>
>> Create level-0 backup, as usual:
>> nbackup -B 0 source.fdb source-0.nbk
>>
>>
23.03.2016 17:31, Dmitry Yemanov wrote:
> 23.03.2016 18:14, Vlad Khorsun wrote:
>>
>> Original patch contains just "-I" switch :) For me both "inplace" and "merge"
>> are ok, let decide what to use.
>
> My point was to replace two switches (-inplace -restore) with one
> (-merge or whatever).
Go
24.03.2016 10:56, Dmitry Yemanov wrote:
> 24.03.2016 11:33, Vlad Khorsun wrote:
>
>>> May I suggest to add isc_info_* code to query the backup GUID via
>>> isc_database_info()? Parsing gstat output for it is very awful.
>>
>> I have same idea. I suppose it is better to return GUID in text
>> repres
24.03.2016 9:56, Dmitry Yemanov wrote:
> I'm not that sure. API is for programmers and it's intended to work with
> binary data. Whoever able to call isc_database_info() may easily call
> (or implement) a function to format it into text.
+1.
Especially if nbackup service will accept binary U
Vlad Khorsun wrote Wed, 23 Mar 2016 17:43:23
+0300:
>
>Let me show how it works. It is very simplified example, of course.
>
> Create database source.fdb.
>
> Create level-0 backup, as usual:
>nbackup -B 0 source.fdb source-0.nbk
>
> Restore level-0 backup, as usual:
> nbackup -R targ
24.03.2016 11:33, Vlad Khorsun wrote:
>> May I suggest to add isc_info_* code to query the backup GUID via
>> isc_database_info()? Parsing gstat output for it is very awful.
>
> I have same idea. I suppose it is better to return GUID in text
> representation, not binary, agree ?
I'm not that sure
24.03.2016 9:42, Pavel Cisar wrote:
> Hi,
>
> May I suggest to add isc_info_* code to query the backup GUID via
> isc_database_info()? Parsing gstat output for it is very awful.
I have same idea. I suppose it is better to return GUID in text
representation, not binary, agree ?
> New nbackup sw
Hi,
May I suggest to add isc_info_* code to query the backup GUID via
isc_database_info()? Parsing gstat output for it is very awful. New
nbackup switches and options should be also handled by services API.
best regards
Pavel Cisar
IBPhoenix
23.03.2016 18:14, Vlad Khorsun wrote:
>
> Original patch contains just "-I" switch :) For me both "inplace" and "merge"
> are ok, let decide what to use.
My point was to replace two switches (-inplace -restore) with one
(-merge or whatever).
Dmitry
23.03.2016 17:01, Dmitry Yemanov wrote:
> 23.03.2016 17:43, Vlad Khorsun wrote:
>>
>> apply new increment to the target database:
>>nbackup -INPLACE -R target.fdb source-inc.nbk
>
> Wouldn't something like "nbackup -merge" be more user-friendly?
Original patch contains just "-I" sw
23.03.2016 17:43, Vlad Khorsun wrote:
>
> apply new increment to the target database:
> nbackup -INPLACE -R target.fdb source-inc.nbk
Wouldn't something like "nbackup -merge" be more user-friendly?
Dmitry
--
23.03.2016 14:32, Dmitry Kuzmenko wrote:
> Здравствуйте!
>
> Tuesday, March 22, 2016, 4:40:23 PM, you wrote:
>>> 2) We added option into NBACKUP utility to create change set based on
>>> baseline GUID rather than level.
>
> VK>Basic tests show it works :) If anyone have idea how to improve it
Здравствуйте!
Tuesday, March 22, 2016, 4:40:23 PM, you wrote:
>> 2) We added option into NBACKUP utility to create change set based on
>> baseline GUID rather than level.
VK>Basic tests show it works :) If anyone have idea how to improve it - you
are welcome.
VK> For example, we could intro
20.04.2013 21:24, Nikolay Samofatov wrote:
> Hello, All!
>
> We use NBACKUP for physical replication of the databases. For that we added 2
> features:
>
> 1) We only read one sector (with header) of each page when scanning for
> changes. This is helpful for
> SSD media and might provide 4x-32x sp
Hello.
Thanks for review.
> Thanks.
>
> After quick review i want to point to a trivial bug in
> NBackup::backup_database()
>
> short null_flag = 0;
> - in_sqlda->sqlvar[0].sqldata = (char*) &level;
> - in_sqlda->sqlvar[0].sqlind = &null_flag;
> + if (level >= 0)
> + {
> + in
> Patch against FB HEAD in attach.
Thanks.
After quick review i want to point to a trivial bug in
NBackup::backup_database()
short null_flag = 0;
- in_sqlda->sqlvar[0].sqldata = (char*) &level;
- in_sqlda->sqlvar[0].sqlind = &null_flag;
+ if (level >= 0)
+ {
+ in_sqlda->sqlvar[
Hello, all.
Ok, I ask Dmitry Starodubov to create a patch for FB3.0 and publish it
for review.
Nikolay
Patch against FB HEAD in attach.
Dmitry
Index: lang_helpers/gds_codes.ftn
===
--- lang_helpers/gds_codes.ftn (revision 580
Hello, Vlad!
>> To update offline copy of the database over WAN we use the following
>> procedure in a shall script:
>> - obtain baseline GUID of the database using GSTAT -h
>> - pull changes using SSH+NBACKUP using baseline GUID
> What is the file format where changes are stored ?
The same
20.04.2013 21:24, Nikolay Samofatov wrote:
> Hello, All!
>
> We use NBACKUP for physical replication of the databases. For that we added 2
> features:
>
> 1) We only read one sector (with header) of each page when scanning for
> changes. This is helpful for
> SSD media and might provide 4x-32x sp
19 matches
Mail list logo
