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
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
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 plain text file
: archiving data
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
.
Arup Nanda
www.proligence.com
- 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 sqlplus limitation of 64k
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 like
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
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
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
[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 sqlplus limitation of 64k and
any data longet than 64k will get truncated in this
case too..
correct me if i am wrong,even
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 one
of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Saturday, May 31, 2003 6:29 PM Subject: Re: archiving data 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
hi there is this project that is going on for
archiving old data from oltp system that is older than
12 months and then purging them in the main db.
the tables that are to be archived are with long rows.
they cannot be converted to lobs since this is a third
party application. here is where the
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
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 kids
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
The Emulation Solution
Research Required for the Emulation Approach
Summary
References
---end---
On 15 Apr 2002 at 9:49, [EMAIL PROTECTED] wrote:
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
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
their requirements for
archiving data as their system is 4 years old and billing data is piling
up which obviously is affecting performance. I am pushing for an Oracle
upgrade, they are currently on 7.3.4 and I am trying to get them to go
to 9i. The main reason for this is so they can use partitioning.
My
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
posted this question to the Lazydba List and got a couple
of replies, but thought I would also send it to this list as well to see
if I can just get a couple more (so excuses to those people that have
already seen it)
I am currently discussing with a customer their requirements for
archiving data
their requirements for
archiving data as their system is 4 years old and billing data is piling
up which obviously is affecting performance. I am pushing for an Oracle
upgrade, they are currently on 7.3.4 and I am trying to get them to go
to 9i. The main reason for this is so they can use partitioning.
My question
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
I have few tables that will be getting populated with transaction data
continuously.This table
grows to large size.For us once the transaction is completed we don't need
the data to be in the database,
but we cannot delete them either.We need to archive those records and clear
those archived
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 will be getting populated
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
26 matches
Mail list logo
