Hi Andreas, Glad I could help :)
The main difference is that export will effectively cease all activity for the selected database. From the internal point of view, it is a client application that reads all the data in the database. Since it acts as an all-reading transaction it read-locks the database. Hot-backup behaves differently. It acts in parallel with user activity. Again, from the internal point of view, it goes no further than Sedna SM process. It copies data file and logical log files. So you can say that export is a _logical_ dump, with exported documents lying there in XML format. Later, documents and indexes could be recreated with bulk-loads and some usual XQuery queries (that's what import does actually). On the other hand, hot-backup is a _binary_ dump, consisting of your usual data and log files. One of the interesting features of hot-backup is an opportunity to make incremental backups: first, you make your usual hot-backup and then you periodically perform incremental ones. They consist only of the changes made from the previous hot-backup. From the internal point of view, incremental part of hot-backup consists only of log files that were written from the moment of the previous hot-backup. Oh, and there is another important thing -- hot-backup is restored using usual recovery process: you just copy all these data and log files and start se_gov and se_sm. It could be considerably faster sometimes in comparison with running all these bulk-loads and XQuery queries for import. On the other hand, hot-backup cannot guarantee reliable migration between major Sedna releases and, in some very rare cases, between different machines. It is binary after all, and you cannot interfere with the process. Since export represents its data in user-friendly way, it provides more reliable means of migration and you can edit-hack all these XQuery and XML files if you need to. OK, I hope I haven't been too vague this time :) Let me sum this up: Export: -- is a logical dump, representing its data with XQuery and XML. -- effectively stalls any user activity -- provides reliable migration between major releases Hot-backup: -- is a binary dump of the database -- works without hindering user activity -- has incremental feature -- is usually much faster to make and to recover from I'm also sending this to sedna-discussion list, since this info could be interesting to others. Best regards, Alexander. On 07/25/2010 01:38 PM, Andreas Weiler wrote: > Hi Alexander, > > Thanks a lot that explanation worked out for me. > > So i have one more question: > What is exactly the difference between export a database and Hot > Backup it? > > Thx in advance, > Kind regards > Andreas > > Alexander Kalinin schrieb: >> Hi Andreas, >> >> Ivan asked me to answer your questions about versioning in Sedna. >> Here it goes: >> >> 1) We have 2 snapshots per database. They are used for read-only >> transactions only. There is a third one, but it's used for recovery >> only. If you need some details on that, let me know. >> 2) A page is a synonym for a database block. So, a document consists >> of several pages. >> >> OK, here is an example. In a nutshell, that's what can happen when >> some transaction requires a block (page): >> >> 1) It's an update transaction and it wants to read the block -- SM >> process gives it the last version of the block (S2PL takes care of >> concurrency issues here). >> 2) It's an update transaction and it wants to write something to the >> block. We've got two cases here: >> a) This transaction hasn't yet written to the block. Then SM >> creates a new version for the block, and transaction starts write >> into it. >> b) Transaction have written something in the same block. Then >> the version of the block has already been created, and transaction >> continues to write into it. >> 3) It's a newcomer read-only transaction (we often call them >> queries). Remember the 2 snapshots? The transaction gets the blocks >> from the most recent one. >> 4) It's a read only transaction wanting to read another block. It >> receives versions from the same snapshot it started to read on the >> first request. >> >> There are some other issues: >> >> 1) Why do we need 2 snapshots? The answer is simple. Since >> transaction reads the same snapshot until is commits, we cannot >> 'advance' the snapshot until there are no transactions reading it. So >> to make data for queries less obsolete we create another one. And all >> newcomer queries read the new snapshot. Actually, we can have more >> than 2 snapshots. As you probably understand it's a trade-off between >> reading more obsolete data and consuming more disk space. The number >> of snapshots is a compile-time constant. >> 2) All versions of the same block are accessible from the last >> version of the block. This version contains pointers to them in its >> header. >> >> Hope that helps. >> >> Best regards, Alexander. >> >> >> On 07/19/2010 11:51 AM, Ivan Shcheklein wrote: >>> >>> ---------- Forwarded message ---------- >>> From: *Andreas Weiler* <[email protected] >>> <mailto:[email protected]>> >>> Date: Sat, Jul 17, 2010 at 1:49 PM >>> Subject: Re: Survey on XML Databases >>> To: Ivan Shcheklein <[email protected] >>> <mailto:[email protected]>> >>> >>> >>> Hi Ivan, >>> >>> again, thanks a lot for your answers. >>> Probably i can ask another question regarding the multiversioning >>> for concurrency control. >>> Your Paper Sedna: Native XML Database Management System (Internals >>> Overview) is describing it >>> very good but im not 100% sure i did understand right. >>> >>> Is there one snapshot per transaction or per database or...? >>> A page is a copy of a whole document? >>> Maybe you can describe the whole concept with an example? >>> >>> Thank you very much in advance, >>> >>> kind regards, >>> Andreas >>> >>> Ivan Shcheklein schrieb: >>> >>> Hi Andreas, >>> >>> >>> >>> Please, find answers below. For details refer to the Sedna >>> Internals section on >>> http://modis.ispras.ru/sedna/documentation.html . >>> >>> 1. Art of Server? like own implementation...web-server etc... >>> >>> >>> Own implementation. Description of the client-server protocol is >>> available here: >>> >>> http://modis.ispras.ru/sedna/serverprotocol/ClientServerProtocol.html >>> 2. Communication between Server and Client? TCP/IP...etc... >>> >>> >>> TCP/IP >>> 3. Queries? XQuery, XPath... >>> >>> >>> XQuery 1.0 (XPath is subset of XQuery) + own proprietary >>> functions for indexes, full-test indexes, SQL connection. >>> Documentation of all these function is available on our site. >>> 4. Updates? XQuery Update, XUpdate, own functions... >>> >>> >>> XUpdate language based on Patrick Lehti proposal. >>> 5. Recovery? Backup, Hot Backup, Restore... >>> >>> >>> Hot backup (including incremental hot backup), backup with >>> export/import utility. Documentaion is also available on our site. >>> 6. Transactions? Optimistic with commit and rollback, >>> pesimistic >>> with check before execution etc... >>> >>> >>> ACID transactions based on versioning mechanism. >>> 7. Locking? Document level, Database level, Node >>> level...with >>> Two-Phase-Locking etc... >>> >>> >>> Pessimistic, S2PL protocol. Granularity: documents, collections, >>> database, indexes. >>> >>> >>> Ivan Shcheklein, >>> Sedna Team >>> >>> >>> > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Sedna-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sedna-discussion
