RENAMING MNESIA TABES

[Valentin]

Thanks Chandru (and Sean) for your advices. Highly appreciated.
Doing and traversing the backup might just do the trick!!!

V.

----- Original Message -----
From: "Chandrashekhar Mullaparthi"
<Chandrashekhar.Mullaparthi@REDACTED>
To: "'Valentin'" <valentin@REDACTED>; "Chandrashekhar Mullaparthi"
<Chandrashekhar.Mullaparthi@REDACTED>; <erlang-questions@REDACTED>
Sent: Monday, December 16, 2002 1:02 PM
Subject: RE: RENAMING MNESIA TABES


> Take a backup of the database and then do your export by traversing the
> backup. The backup process is quite efficient and quick. The functions of
> interest to you would be mnesia:backup and mnesia:traverse_backup - check
> the user guide for mnesia as well - there is an example of traversing a
> mnesia backup file. You can traverse the backup in a different mnesia node
> as well.
>
> Tip: when writing to your CSV file, dont write one line at a time. Write a
> bunch of lines at a time. This will considerably speed up your export
> process.
>
> cheers
> Chandru
>
> -----Original Message-----
> From: Valentin [mailto:valentin@REDACTED]
> Sent: 16 December 2002 10:52
> To: Chandrashekhar Mullaparthi; erlang-questions@REDACTED
> Subject: Re: RENAMING MNESIA TABES
>
>
> We have a requirement to export some historical/log data from MNESIA into
> ORACLE. The data in MNESIA table is short-lived, that is, once the data
has
> been exported, the MNESIA table is recreated (we find it much faster to
> recreate a table than to use mnesia:clear_table/1).
>
> At the time, the easiest way to achieve this was to run a single process
> that will receive log messages and store them into MNESIA table. Once a
day,
> say, at midnight, the same process would export data into CSV file, whilst
> any message  "posted" during this time will remain in the queue and will
be
> inserted once the export was completed... Some external process uploads
such
> a CSV file into the ORACLE.
>
> This process has worked just fine so far, however, as it usually happens,
we
> have underestimated the traffic volumes, and I am not sure if the process
> will cope with the load -- the export facility that I wrote is quite a
slow
> one. I've been looking for a simple work-around,  i.e. if  the table can
be
> renamed, I would have all the time in the world to do the export, etc.
>
> Well, it's a back to the drawing board for me, I guess :-(
>
> V.
>
>
> ----- Original Message -----
> From: "Chandrashekhar Mullaparthi"
> <Chandrashekhar.Mullaparthi@REDACTED>
> To: "'Valentin'" <valentin@REDACTED>; <erlang-questions@REDACTED>
> Sent: Monday, December 16, 2002 10:28 AM
> Subject: RE: RENAMING MNESIA TABES
>
>
> > There isn't a way to rename a table. You'll have to create a new table,
> copy
> > the contents and delete the old table. But why do you want to do such a
> > thing? What is the problem you're tackling?
> >
> > Chandru
> >
> > -----Original Message-----
> > From: Valentin [mailto:valentin@REDACTED]
> > Sent: 15 December 2002 13:14
> > To: erlang-questions@REDACTED
> > Subject: RENAMING MNESIA TABES
> >
> >
> > Any idea how to rename a mnesia table? Consider the following scenario:
> >
> > 1) process P1 writes to table T1
> > 2) table T1 is renamed to T2
> > 3) process P1 fails to write while T1 is not available (new messages
> (data)
> > are accumulated in P1's queue while P1 retries to write to T1)
> > 4) a new T1 is created
> > 5) process P1 writes to T1
> >
> > I am worried that something like this is not possible, as it would
> > complicate transactions, etc. Hope that I'm wrong, as it would make my
> life
> > so much simpler.
> > I've been looking at fragmentation, but that doesn't seem to be a simple
> > solution for (I hope) a simple problem.
> >
> > Valentin.
>
>
>
> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential.  If you have received
> this email in error please notify the sender immediately and delete this
> email from your system without copying or disseminating it or placing any
> reliance upon its contents.  We cannot accept liability for any breaches
of
> confidence arising through use of email.  Any opinions expressed in this
> email (including attachments) are those of the author and do not
necessarily
> reflect our opinions.  We will not accept responsibility for any
commitments
> made by our employees outside the scope of our business.  We do not
warrant
> the accuracy or completeness of such information.
>