RE: archiving data

2003-06-04 Thread Paula_Stankus
Title: RE: archiving data Hmmm.  thought I was just mailing that to Dennis.    Sorry,   Now I do my Pat laugh -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 03, 2003 9:25 PMTo: Multiple recipients of list ORACLE-LSubject: RE

RE: archiving data

2003-06-04 Thread Paula_Stankus
Title: RE: archiving data Thanks Dennis for the encouragement. I really try not to take it out on them.  I work for the financial security of my family but I also don't want it to impact (or at least as little as possible) my relationship with my kids.  I feel as their mother I need

Re: archiving data

2003-06-02 Thread Arup Nanda
; of LONG column copied is 2 GB; actually 2,000,000,000 bytes, not 64K. You > >> have to specify the size of long in your session using SET LONG 200000 > >> before attempting the copy command. > >> > >> Please let us know where you found that 64K limitation.

Re: archiving data

2003-06-02 Thread Tim Gorman
found that 64K limitation. The ohter thin you >> have to consider is that COPY is being depecrated in 10i, or whatever it >> will be called; but then again, I hope your application will have ceased >> using LONGs. >> >> Arup Nanda >> www.prolige

Re: archiving data

2003-06-01 Thread Arup Nanda
Subject: Re: archiving data thanks a bunch for this test case...it surely will help me a lot   saiArup Nanda <[EMAIL PROTECTED]> wrote: I just did a few tests with a LONG field in a table. Final Answer: data morethan 64K is properly loaded using COPY.Test SetupUsed a

Re: archiving data

2003-06-01 Thread Sai Selvaganesan
> ---! -- Original Message -> From: "Sai Selvaganesan" <[EMAIL PROTECTED]>> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>> Sent: Saturday, May 31, 2003 6:29 PM> Subject: Re: archiving data>>> > but i think there is a sqlp

Re: archiving data

2003-06-01 Thread Sai Selvaganesan
hi   i read thru this document id # 1022033.6 in metalink which says the follwoing Use the Copy Command with Longs and Long Raw:   The COPY command is one way to get long data from on

Re: archiving data

2003-06-01 Thread Arup Nanda
application will have ceased > using LONGs. > > Arup Nanda > www.proligence.com > > - Original Message - > From: "Sai Selvaganesan" <[EMAIL PROTECTED]> > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Saturday, May 3

RE: archiving data

2003-06-01 Thread DENNIS WILLIAMS
Paula - Sorry to hear you are having problems. Since your posting time was last night, hope you fixed the problem in time to have a weekend with your kids. I get hit by the same thing now and then. You are right that you want to see your family, but when you are tired and grumpy they may not enjoy

Re: archiving data

2003-06-01 Thread Arup Nanda
Sai, Where did you find that limitation of 64K? Although I admit I have not used a long column of that size, but according to the fine manuals, the max size of LONG column copied is 2 GB; actually 2,000,000,000 bytes, not 64K. You have to specify the size of long in your session using SET LONG 200

RE: archiving data

2003-06-01 Thread DENNIS WILLIAMS
Sai I would research that before making an assumption. The COPY command is a bit different from anything else in Oracle. I found the following note with a quick Google search: "Note that sqlplus COPY has a port specific limit on the maximum size of LONG you can copy. Refer to the SQLPLUS Us

Re: archiving data

2003-06-01 Thread Sai Selvaganesan
but i think there is a sqlplus limitation of 64k and any data longet than 64k will get truncated in this case too.. correct me if i am wrong,even if u set long to a very high value,data more than 64k in lenght will get truncated . sai --- Arup Nanda <[EMAIL PROTECTED]> wrote: > For situations li

Re: archiving data

2003-05-31 Thread Arup Nanda
For situations like this you have the COPY command of SQL*Plus. Remember, it's a SQL*Plus comamnd like set, btitle, etc. not a sql command you can embed inside a pl/sql block. You could create a table similar in structure to main table and then polulate the data SQL> SET LONG 99 -- this is ne

RE: archiving data

2003-05-31 Thread Paula_Stankus
Title: RE: archiving data I/O failure this week.  Productional system restore/verified and backed up - fully operational once I/O subsystem rebuilt in 2.5 hours - required full restore because key datafiles corrupted - system, redos, control.  Waiting for I/O took longest didn't see

Re: archiving data

2003-05-31 Thread Joe Testa
how do you define "older than 12 months"?? are you using enterprise edition and is it feasible to use partitioning?, if you partition on the field that defines "older than 12 months", its easy enough to drop a partition(or exchange a partition with a non-partitioned table, export that and drop

Re: Archiving Data Strategies.

2002-04-18 Thread Eric D. Pierce
Council on Library and Information Resources http://www.clir.org/home.html - http://www.clir.org/pubs/issues/issues25.html#plan - -- http://www.clir.org/pubs/reports/rothenberg/contents.html Avoiding Technological Quicksand: Finding a Viable Technical Foundation for Digital Preservatio

Re: Archiving Data Strategies.

2002-04-15 Thread Jared . Still
Ian, I've put of replying to this for a couple of weeks now. I see that no one else has replied either, at least to the list. Archiving data is a rather complex subject. When data is taken offline and archived, there are a number of things to consider. * algorithms for archiving. Your appl

Re: Archiving Data Strategies.

2002-03-27 Thread Mohammad Rafiq
It depends on Application and hardware availability like disk space. It is mix and match situation. With 7.3.4 neither you have partioning option nor to export old data using query option from source table and delete rows from that table. If you are talking about Oracle Financials database , i

RE: Archiving Data Strategies.

2002-03-27 Thread Hately Mike
Ian, Partitioning is a great way to archive stuff as long as there are no logical dependencies on it from data that will stay active. You're then able to convert the partition to archive table or just drop it if business rules allow. If you make sure that partitions are in separate tablespaces you

RE: Archiving Data Strategies.

2002-03-27 Thread Hallas John
Title: RE: Archiving Data Strategies. As you say Ian partitioning is a obvious answer as I imagine the billing data will be quite easy to range partition using dates. However why go to 9i, 8i has many partitioning options and it may be an easier upgrade as well as a leap that management

Re: Archiving data

2001-08-31 Thread Ron Rogers
Ravindra, That is basically what I do each 6 months for 6 large tables. I created a function that will insert the rows into an existing table and commit after so many rows. Then I use a script to delete the rows from the original table by date range and commit after each range specified. It wor

RE: Archiving data

2001-08-30 Thread Ravindra Basavaraja
Title: RE: Archiving data The database is running on older versions not on 8.0(i guess 7.3.4) .This is at one of the customers site and the solution is for that database. They might upgrade to new version after few months but till then we got to live with that.     -Original Message

RE: Archiving data

2001-08-30 Thread Jacques Kilchoer
Title: RE: Archiving data This sounds like a textbook case for table partitioning. Read the manual on partitions. You ARE on oracle 8.0 or above, I imagine? > -Original Message- > From: Ravindra Basavaraja [mailto:[EMAIL PROTECTED]] > > I have few tables that wil