Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.misc -> Re: 40 gig big oracle database can be done smaller ?
On May 23, 3:09 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>
>
> Ed Yin wrote:
> > Hello,
>
> > Can someone answere my questions about a hypothetical case..
>
> > Let say i run a 9.* oracle database on a unix platform about 40 gig big with
> > employee data in it and i want to chop it into peaces what would be the
> > smartest thing to do if possible.
>
> > what do i want to accomplish with this action:
>
> > let say an error ocurred and i need to stop/restart the database all
> > database users have to logout or something equal. or i need to add
> > tablespaces or add or change datafiles.
>
> > if i have "in my words" more then 1 database let say emp names A and B in
> > DB1, C and D emp names in DB2 and i have a problem within DB1 should the
> > users using DB2 not be influenced by the DB1 error ?
>
> > And can some explain if it is possible and how it is done for example to
> > make 1 connection or do 1 update form a application to the 1 record in DB1
> > or DB2 all in relation to the questions above.
>
> > sorry for bad english i hope i wrote my idea in understandable english :)
>
> > thanks Ed
>
> 40GB is not big; I have 788GB free space on my H: drive (at home!), and
> an unused 300GB HD in this PC.
> Let's not go there: disks are cheap, unless you buy them with stickers
> from the main OS vendors.
> Even then, they are cheap compared with labor and overhead.
>
> In short: the smartest thing to do would be not to chop.
> There's absolutely no gain, but so much pain - you'll have to maintain
> a second instance, with exactly the same "issues" you now have.
> So - you double your trouble.
>
> Errors do not occur in a matter you will have to restart databases
> every day. They are exceptions, not rule, and therefor not an
> argument.
>
> Adding datafiles to tablespaces can be done online - with your
> users executing transactions.
> But yes, you are correct in the assumption that if "A" and "B"
> data resides in database1 and "C" and "D" on database2, downtime
> on 1 does not affect data on 2. However, I see no mechanism to
> allow one application to make connections to two different
> instances, based on the *contents* of tables.
> - --
> Regards,
> Frank van Bortel
>
> Top-posting is one way to shut me up...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (MingW32)
>
> iD8DBQFGU+iOLw8L4IAs830RAm/zAJ9M8q+j5ZQpzsiEUUxJrFDPMwUVsQCfUEqL
> sV9leLHWjSPepazqjbV855k=
> =X/Cw
> -----END PGP SIGNATURE------ Hide quoted text -
>
> - Show quoted text -
I agree with Daniel and Frank. Also I want to point out that activities such as adding new tablespaces, or adding files to existing tablespace do not require that you take exclusive control of the database. Many routine maintenance tasks can be done while the database is in normal use.
HTH -- Mark D Powell -- Received on Wed May 23 2007 - 08:47:29 CDT
![]() |
![]() |