Re: DB Tables on separate hardisks
I agree, I would not recommend building an application assuming the following will always work (and it may even only partially work and fail in some manner during recovery in the future). Out of curiosity, what is driving the request. Is it I/O throughput, or just that you have space on 2 disks rather than one? Daniel John Debrunner wrote: David W. Van Couvering wrote: Well, it's tricky to do symbolic links since Derby creates the tables within a directory. I guess what you could do is create the tables, shut down Derby, move the table(s) to a different disk device, create a soft link, and start Derby up again. Hey, that might work! (ever the optimist) Since that's obviously not how Derby is intended to function, don't assume such tricks will always work in the future. Or even now. Compress table, rollback of a drop table and other functionality will all move the files back (I think) to their intended location. In the future automated space re-allocation work might perform similar renames on the files. Dan.
RE: DB Tables on separate hardisks
Yeah,
That is exactly what I was thinking. However, sometimes databases get flakey
when you try to use symbolic links. At least this was a dirty trick back in
the Informix Standard Engine Days. However, if Derby is using the standard
Java IO, then you shouldn't have a problem with symbolic links.
But you're going to have a headache every time you want to configure or
modify the database. (adding, dropping and even altering a table can be
problematic.)
One has to ask why they would want to do this? The only thing I could think
of is that you may have some sort of file system constraint and your
database is going beyond it. Even then, Derby wouldn't be the correct
database to use.
Performance? (use different file systems located on different disks?)
That would also be an indication that you're using the wrong product... of
course I'm assuming that you've already gone through a series of code
reviews and tuned the engine to be its most efficient.
While I haven't started hitting the scotch yet, has anyone tried running
Derby from a networked drive? (NFS for example?) What would happen if you
had derby on a public drive that was networked from two different machines
each trying to run Derby in either in embedded or network mode?
Not that I recommend it, just trying to see where and how it would fail.
(Assuming system lock management would die, or file io ...)
Of course the other idea of running each table in a separate instance may
have merit. You could in theory try to create a Derby MPP database but again
you'd have a lot of work to do.
Oh well, lunch break over. Back to real work.
-G
-Original Message-
From: David W. Van Couvering [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 11:26 AM
To: Derby Discussion
Subject: Re: DB Tables on separate hardisks
Well, it's tricky to do symbolic links since Derby creates the tables
within a directory. I guess what you could do is create the tables,
shut down Derby, move the table(s) to a different disk device, create a
soft link, and start Derby up again. Hey, that might work! (ever the
optimist)
David
Michael Segel wrote:
> On Thursday 26 January 2006 3:19 pm, Rajesh Kartha wrote:
>
>>Only the database logs can be put on a separate device using the
>>'logDevice' attribute
>>
>>http://db.apache.org/derby/docs/10.1/adminguide/cadminlog98.html
>>
>>Please refer the Derby Admin Guide for more information on this.
>>
>>-Rajesh
>>
>
> Well
>
> If you wanted to do something down and dirty, you could always have a
couple
> of different instances running and then connect to the correct instance to
> write the table out and have each instance point to a different directory.
> (But that's a lot of headache and its going to be a nightmare to
maintain.)
>
> I guess there may be one other option, that might work.
>
> Has anyone tried doing either symbolic links or hard links? How will Derby
> handle this? In theory, it should work
>
>
>>On 1/26/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
>>
>>>My understanding is this is not possible right now with Derby.
>>>
>>>David
>>>
>>>Melvin Zamora wrote:
>>>
>>>>Hi Derbies,
>>>>
>>>>Would it be possible to have the PK tables on hardisk-A and FK tables
>>>>on hardisk-B using only one database?
>>>>
>>>>to envision:
>>>>
>>>>CUSTOMER_DERBY_DB
>>>>
>>>>CUSTOMER_TBL {PK} [HD-A], CUSTOMER_PURCHASES_TBL {FK} [HD-B]
>>>>
>>>>-Melvin
>>>>
>>>>---
>>>>-
>>>>
>>>>Do you Yahoo!?
>>>>With a free 1 GB, there's more in store with Yahoo! Mail.
>>>><http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo
>>>>.com/
>
>
Re: DB Tables on separate hardisks
There is no support for this in Derby. What is usually recommended in
this situation is to use the OS to stripe the 2 disks, and create a
single volume out of the 2 and then create the derby db on the single
volume. I believe all the major OS's support this in some manner.
Melvin Zamora wrote:
Hi Derbies,
Would it be possible to have the PK tables on hardisk-A and FK tables on
hardisk-B using only one database?
to envision:
CUSTOMER_DERBY_DB
CUSTOMER_TBL {PK} [HD-A], CUSTOMER_PURCHASES_TBL {FK} [HD-B]
-Melvin
Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail.
Re: DB Tables on separate hardisks
David W. Van Couvering wrote: > Well, it's tricky to do symbolic links since Derby creates the tables > within a directory. I guess what you could do is create the tables, > shut down Derby, move the table(s) to a different disk device, create a > soft link, and start Derby up again. Hey, that might work! (ever the > optimist) Since that's obviously not how Derby is intended to function, don't assume such tricks will always work in the future. Or even now. Compress table, rollback of a drop table and other functionality will all move the files back (I think) to their intended location. In the future automated space re-allocation work might perform similar renames on the files. Dan.
Re: DB Tables on separate hardisks
Well, it's tricky to do symbolic links since Derby creates the tables
within a directory. I guess what you could do is create the tables,
shut down Derby, move the table(s) to a different disk device, create a
soft link, and start Derby up again. Hey, that might work! (ever the
optimist)
David
Michael Segel wrote:
On Thursday 26 January 2006 3:19 pm, Rajesh Kartha wrote:
Only the database logs can be put on a separate device using the
'logDevice' attribute
http://db.apache.org/derby/docs/10.1/adminguide/cadminlog98.html
Please refer the Derby Admin Guide for more information on this.
-Rajesh
Well
If you wanted to do something down and dirty, you could always have a couple
of different instances running and then connect to the correct instance to
write the table out and have each instance point to a different directory.
(But that's a lot of headache and its going to be a nightmare to maintain.)
I guess there may be one other option, that might work.
Has anyone tried doing either symbolic links or hard links? How will Derby
handle this? In theory, it should work
On 1/26/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
My understanding is this is not possible right now with Derby.
David
Melvin Zamora wrote:
Hi Derbies,
Would it be possible to have the PK tables on hardisk-A and FK tables
on hardisk-B using only one database?
to envision:
CUSTOMER_DERBY_DB
CUSTOMER_TBL {PK} [HD-A], CUSTOMER_PURCHASES_TBL {FK} [HD-B]
-Melvin
---
-
Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail.
Re: DB Tables on separate hardisks
On Thursday 26 January 2006 3:19 pm, Rajesh Kartha wrote:
> Only the database logs can be put on a separate device using the
> 'logDevice' attribute
>
> http://db.apache.org/derby/docs/10.1/adminguide/cadminlog98.html
>
> Please refer the Derby Admin Guide for more information on this.
>
> -Rajesh
>
Well
If you wanted to do something down and dirty, you could always have a couple
of different instances running and then connect to the correct instance to
write the table out and have each instance point to a different directory.
(But that's a lot of headache and its going to be a nightmare to maintain.)
I guess there may be one other option, that might work.
Has anyone tried doing either symbolic links or hard links? How will Derby
handle this? In theory, it should work
> On 1/26/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
> > My understanding is this is not possible right now with Derby.
> >
> > David
> >
> > Melvin Zamora wrote:
> > > Hi Derbies,
> > >
> > > Would it be possible to have the PK tables on hardisk-A and FK tables
> > > on hardisk-B using only one database?
> > >
> > > to envision:
> > >
> > > CUSTOMER_DERBY_DB
> > >
> > > CUSTOMER_TBL {PK} [HD-A], CUSTOMER_PURCHASES_TBL {FK} [HD-B]
> > >
> > > -Melvin
> > >
> > > ---
> > >-
> > >
> > > Do you Yahoo!?
> > > With a free 1 GB, there's more in store with Yahoo! Mail.
> > > > >.com/
--
--
Michael Segel
Principal
Michael Segel Consulting Corp.
[EMAIL PROTECTED]
(312) 952-8175 [mobile]
Re: DB Tables on separate hardisks
Only the database logs can be put on a separate device using the 'logDevice' attribute
http://db.apache.org/derby/docs/10.1/adminguide/cadminlog98.html
Please refer the Derby Admin Guide for more information on this.
-RajeshOn 1/26/06, David W. Van Couvering <
[EMAIL PROTECTED]> wrote:
My understanding is this is not possible right now with Derby.DavidMelvin Zamora wrote:> Hi Derbies,>> Would it be possible to have the PK tables on hardisk-A and FK tables on> hardisk-B using only one database?
>> to envision:>> CUSTOMER_DERBY_DB>> CUSTOMER_TBL {PK} [HD-A], CUSTOMER_PURCHASES_TBL {FK} [HD-B]>> -Melvin>>
> Do you Yahoo!?> With a free 1 GB, there's more in store with Yahoo! Mail.> <
http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/
>>
Re: DB Tables on separate hardisks
My understanding is this is not possible right now with Derby.
David
Melvin Zamora wrote:
Hi Derbies,
Would it be possible to have the PK tables on hardisk-A and FK tables on
hardisk-B using only one database?
to envision:
CUSTOMER_DERBY_DB
CUSTOMER_TBL {PK} [HD-A], CUSTOMER_PURCHASES_TBL {FK} [HD-B]
-Melvin
Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail.
