Re[2]: [firebird-support] Gbak and service manager
Hello, Rick! Friday, October 21, 2011, 6:30:17 PM, you wrote: RD> Thanks. btw, services api backup and restore is the fastest in comparison with the non-service API local and tcp protocols - from 2 to 5 times. We made tests in 2008-2009, and discovered that. So, if you wanna speed, use Services API. You can simply compare this by yourself. example picture of restore 1.5 gb database on desktop with separate disks for temp, db and backup: http://www.ibase.ru/devinfo/rs-win-prot-full.gif "services" - using -se option local and tcp - not using -se option. p.s. 2.5 tests was made with RC2 or RC3, don't remember, and don't remember we remade tests with 2.5.0 release or not. Consider 2.1 and 2.5 equal. -- Dmitry Kuzmenko, www.ib-aid.com
RE: [firebird-support] Gbak and service manager
Thanks. -Original Message- From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Kuzmenko Sent: Friday, October 21, 2011 10:06 AM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] Gbak and service manager Hello, Rick! Friday, October 21, 2011, 5:46:26 PM, you wrote: RD> I found a restore script that has been in use for a while that is RD> calling gbak incorrectly. It contains "gbak -se service_mgr" instead of this is local connection (via xnet protocol) RD> "gbak -se localhost:service_mgr". this is tcp connection, not "local" RD> The backup is being restored correctly. Is gbak silently ignoring the RD> -se flag or is it assuming localhost? it is assuming local connection via xnet. -- Dmitry Kuzmenko, www.ib-aid.com ++ Visit http://www.firebirdsql.org and click the Resources item on the main (top) menu. Try Knowledgebase and FAQ links ! Also search the knowledgebases at http://www.ibphoenix.com ++ Yahoo! Groups Links Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.
Re: [firebird-support] Gbak and service manager
Hello, Rick! Friday, October 21, 2011, 5:46:26 PM, you wrote: RD> I found a restore script that has been in use for a while that is RD> calling gbak incorrectly. It contains "gbak -se service_mgr" instead of this is local connection (via xnet protocol) RD> "gbak -se localhost:service_mgr". this is tcp connection, not "local" RD> The backup is being restored correctly. Is gbak silently ignoring the RD> -se flag or is it assuming localhost? it is assuming local connection via xnet. -- Dmitry Kuzmenko, www.ib-aid.com
[firebird-support] Gbak and service manager
I found a restore script that has been in use for a while that is calling gbak incorrectly. It contains "gbak -se service_mgr" instead of "gbak -se localhost:service_mgr". The backup is being restored correctly. Is gbak silently ignoring the -se flag or is it assuming localhost? Thanks, Rick DeBay Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.
