Flarcreate error: too large to archive in current mode

Hi guys,
I try to create a flash archive of a LDOM that holds an Oracle DB. I use the following command:
>
-bash-3.00# flarcreate -n ho811 -S /net/remoteserver/vol1/shared/hor_811.flar
Full Flash
Checking integrity...
Integrity OK.
Running precreation scripts...
Precreation scripts done.
Creating the archive...
cpio: cpio: u01/app/oracle/data/hor811/hor811_data: too large to archive in current mode
cpio: cpio: u01/app/oracle/data/hor811/hor811_index: too large to archive in current mode
20687935 blocks
2 error(s)
Archive creation complete.
Running postcreation scripts...
Postcreation scripts done.
Running pre-exit scripts...
Pre-exit scripts done.
>
/u01/app/oracle/data/hor811/hor811_data and /u01/app/oracle/data/hor811/hor811_index each have 5GB.
Any ideas how to get rid of this errors?
Thank you,
kido
Edited by: kido on May 11, 2011 6:10 PM

Solved in using :
>
flarcreate -n hor811 -L pax -S /net/remote_server/vol1/shared/hor_811_pax.flar
>
which is kinda weird, cause I thought that pax was the default archiver - from man pages:
>
-L archiver
By default, the value for the files_archived_method
field in the identification section is pax(1). If you
specify -L, the archiver (cpio(1) and pax) is used
instead.
>
Well, I guess it's not like that...or maybe I got it wrong...
Now I'm just curious to see if Jumpstart can unpack this archive :)
kido

Similar Messages

Getting Error "too large to archive" while using Tar

Dear All,
I am getting below error while trying to use TAR to acrhive multiple files in one file:
<FileName> too large to archive
The file is of size 2 GB (there are other files with same capacitiy but i am not getting any error for them). Here is waht i am trying to acheive:
(1) Create one tar file from all files in a folder (using tar)
(2) compress the tar file (using compress)
(3) copy the compressed file to the tape (using tar)
One more question, when i use compress (or gzip) command, it create comressed files but original files are not preserved. For example; if i use compress for files a.txt & b .txt it creates a new file (say ab.Z) but removes the files a.txt and b.txt. Is there any option (or any other command) using which i can comress the files without getting them removed?
Thanks in Advance.

Dear Robert,
Thanks for your help. While trying to create tar file using gtar i am now getting below error:
No space left device
So appearantly i don't have enough free space on my file system on which i am trying to create two questions:
(1) Is it possible to compress the tar file resulting from gtar in one command (tar file creation + compress). I don't want files get removed after compression.
(2) Can we directly write to Tape Drive using gtar? Will the size of file resulting from gtar will be same as that of total size of all files or it will be less?
regards,

Too large java heap error while starting the domain.Help me please..

I am using weblogic 10.2,after creating the domain, while starting the domain,I am getting this error.Can anyone help me.Please treat this as urgent request..
<Oct 10, 2009 4:09:24 PM> <Info> <NodeManager> <Server output log file is "/nfs/appl/XXXXX/weblogic/XXXXX_admin/servers/XXXXX_admin_server/logs/XXXXX_admin_server.out">
[ERROR] Too large java heap setting.
Try to reduce the Java heap size using -Xmx:<size> (e.g. "-Xmx128m").
You can also try to free low memory by disabling
compressed references, -XXcompressedRefs=false.
Could not create the Java virtual machine.
<Oct 10, 2009 4:09:25 PM> <Debug> <NodeManager> <Waiting for the process to die: 29643>
<Oct 10, 2009 4:09:25 PM> <Info> <NodeManager> <Server failed during startup so will not be restarted>
<Oct 10, 2009 4:09:25 PM> <Debug> <NodeManager> <runMonitor returned, setting finished=true and notifying waiters>

Thanks Kevin.
Let me try that.
Already more than 8 domains were successfully created and running fine.Now the newly created domain have this problem.I need 1GB for my domain.Is there any way to do this?

XMLTRANSFORM Too large stylesheet - code buffer overflow issue

Hi All,
My question is related to MSWordML generation from PLSQL stored procedure.
1. I have table, containing XSLT stylesheets for different documents
2. PLSQL stored procedure is generating dynamic content depending on some params and at the end I'm using
SELECT XMLTRANSFORM(XMLTYPE.createxml(db_data_clob), XMLTYPE.createxml(x.xslt_clob)).GetClobVal()
INTO res
FROM msword_ml_data x
WHERE x.report_id = rep_id_variable;
where : x.xslt_clob -> column, containing XSLT CLOB
db_data_clob -> dynamic content CLOB
res -> CLOB result
All this was working fine on Oracle11gR1, but I had to reinstall database and I said why not install Oracle11gR2 ...
Guess what. Stored procedure is raising exception when using XMLTRANSFORM :
Exception : : ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00004: internal error "Too large stylesheet - code buffer overflow"
Google says nothing about it. I don't recall setting some special DB property in Oracle11gR1.
Has anyone encountered this ?
I haven't changed procedure nor table.
I'm using exactly the same XSLT's from Java code and they are working just fine, so they are not the reason. My guess is that something in Oracle11gR2 related to XML processing is changed.
If anyone could help, thanks in advance

For those who are interested.
I have logged a service request and it turned out that this is is a bug in Oracle 11gR2.
"The limitation on the style sheet is not exactly a size limit but a limitation on the number of style sheet instructions and depends on the way the style sheet has been written. This is a C based parser limitation"
Anyway, the workaround is to create Java stored procedure and do transformation from there.

"Backup is too large for the backup volume" error

I've been backing up with TM for a while now, and finally it seems as though the hard drive is full, since I'm down to 4.2GB available of 114.4GB.
Whenever TM tries to do a backup, it gives me the error "This backup is too large for the backup volume. The backup requires 10.8 GB but only 4.2GB are available. To select a larger volume, or make the backup smaller by excluding files, open System Preferences and choose Time Machine."
I understand that I have those two options, but why can't TM just erase the oldest backup and use that free space to make the new backup? I know a 120GB drive is pretty small, but if I have to just keep accumulating backups infinitely, I'm afraid I'll end up with 10 years of backups and a 890-zettabyte drive taking up my garage. I'm hoping there's a more practical solution.

John,
Please review the following article as it might explain what you are encountering.
*_“This Backup is Too Large for the Backup Volume”_*
First, much depends on the size of your Mac’s internal hard disk, the quantity of data it contains, and the size of the hard disk designated for Time Machine backups. It is recommended that any hard disk designated for Time Machine backups be +at least+ twice as large as the hard disk it is backing up from. You see, the more space it has to grow, the greater the history it can preserve.
*Disk Management*
Time Machine is designed to use the space it is given as economically as possible. When backups reach the limit of expansion, Time Machine will begin to delete old backups to make way for newer data. The less space you provide for backups the sooner older data will be discarded. [http://docs.info.apple.com/article.html?path=Mac/10.5/en/15137.html]
However, Time Machine will only delete what it considers “expired”. Within the Console Logs this process is referred to as “thinning”. It appears that many of these “expired” backups are deleted when hourly backups are consolidated into daily backups and daily backups are consolidated into weekly backups. This consolidation takes place once hourly backups reach 24 hours old and daily backups reach about 30 days old. Weekly backups will only be deleted, or ‘thinned’, once the backup drive nears full capacity.
One thing seems for sure, though; If a new incremental backup happens to be larger than what Time Machine currently considers “expired” then you will get the message “This backup is too large for the backup volume.” In other words, Time Machine believes it would have to sacrifice to much to accommodate the latest incremental backup. This is probably why Time Machine always overestimates incremental backups by 2 to 10 times the actual size of the data currently being backed up. Within the Console logs this is referred to as “padding”. This is so that backup files never actually reach the physically limits of the backup disk itself.
*Recovering Backup Space*
If you have discovered that large unwanted files have been backed up, you can use the Time Machine “time travel” interface to recovered some of that space. Do NOT, however, delete files from a Time Machine backup disk by manually mounting the disk and dragging files to the trash. You can damage or destroy your original backups by this means.
Additionally, deleting files you no longer wish to keep on your Mac does not immediately remove such files from Time Machine backups. Once data has been removed from your Macs' hard disk it will remain in backups for some time until Time Machine determines that it has "expired". That's one of its’ benefits - it retains data you may have unintentionally deleted. But eventually that data is expunged. If, however, you need to remove backed up files immediately, do this:
Launch Time Machine from the Dock icon.
Initially, you are presented with a window labeled “Today (Now)”. This window represents the state of your Mac as it exists now. +DO NOT+ delete or make changes to files while you see “Today (Now)” at the bottom of the screen. Otherwise, you will be deleting files that exist "today" - not yesterday or last week.
Click on the window just behind “Today (Now)”. This represents the last successful backup and should display the date and time of this backup at the bottom of the screen.
Now, navigate to where the unwanted file resides. If it has been some time since you deleted the file from your Mac, you may need to go farther back in time to see the unwanted file. In that case, use the time scale on the right to choose a date prior to when you actually deleted the file from your Mac.
Highlight the file and click the Actions menu (Gear icon) from the toolbar.
Select “Delete all backups of <this file>”.
*Full Backup After Restore*
If you are running out of disk space sooner than expected it may be that Time Machine is ignoring previous backups and is trying to perform another full backup of your system? This will happen if you have reinstalled the System Software (Mac OS), or replaced your computer with a new one, or hard significant repair work done on your exisitng Mac. Time Machine will perform a new full backup. This is normal. [http://support.apple.com/kb/TS1338]
You have several options if Time Machine is unable to perform the new full backup:
A. Delete the old backups, and let Time Machine begin a fresh.
B. Attach another external hard disk and begin backups there, while keeping this current hard disk. After you are satisfied with the new backup set, you can later reformat the old hard disk and use it for other storage.
C. Ctrl-Click the Time Machine Dock icon and select "Browse Other Time Machine disks...". Then select the old backup set. Navigate to files/folders you don't really need backups of and go up to the Action menu ("Gear" icon) and select "Delete all backups of this file." If you delete enough useless stuff, you may be able to free up enough space for the new backup to take place. However, this method is not assured as it may not free up enough "contiguous space" for the new backup to take place.
*Outgrown Your Backup Disk?*
On the other hand, your computers drive contents may very well have outgrown the capacity of the Time Machine backup disk. It may be time to purchase a larger capacity hard drive for Time Machine backups. Alternatively, you can begin using the Time Machine Preferences exclusion list to prevent Time Machine from backing up unneeded files/folders.
Consider as well: Do you really need ALL that data on your primary hard disk? It sounds like you might need to Archive to a different hard disk anything that's is not of immediate importance. You see, Time Machine is not designed for archiving purposes, just as a backup of your local drive(s). In the event of disaster, it can get your system back to its' current state without having to reinstall everything. But if you need LONG TERM storage, then you need another drive that is removed from your normal everyday working environment.
This KB article discusses this scenario with some suggestions including Archiving the old backups and starting fresh [http://docs.info.apple.com/article.html?path=Mac/10.5/en/15137.html]
Let us know if this clarifies things.
Cheers!

Deployment error "file could not be uploaded because it is too large"

Hi,
I'm trying to deploy a WAR application of 220 mb and the upload page fails the the error "The file could not be uploaded because it is too large". Is there any way to workaround this problem ?. What is the limit for a WAR application ?.
Regards,
Paulo

Paul ,
Currently we have a limit of deployment archive size to be less than 100 MB.
Thanks

Since upgrade to iOS 7 Email error on over 100KB emails "Cannot Send Mail The message was rejected by the server because it is too large." Connecting to Exchange via Activesync

Hi,
Following the upgrade to iOS 7.0.3 on all our iPhone and iPad devices, it has been identified that when sending emails around 100KB in size and over an error message appears on the device stating “Cannot Send Mail The message was rejected by the server because it is too large.” See error message below. The send/receive limit is over 10MB so this is not the issue.
We are in an Exchange Environment using Microsoft Activesync. This issue is not evident in iOS 6. This has been tested on an iPhone 3GS running version iOS 6.1.3. We have been unable to repeat the issues seen on iOS 7 on the older OS. It is not possible to roll back to the older operating system as Apple are no longer signing the software.
We use Microsoft Active Sync to connect to our Exchange servers through a TMG. The issue is very inconsistent, some identical emails go through, some fail. This is not an issue with the send/receive limit as this is over 10MB. The error message when it fails on the TMG is Status: 413 Request Entity Too Large, which we believe is from IIS on the CAS server.
Does anyone have any suggest course of actions to take?
Many Thanks

This resolution have to attend at the server not with the ios device. My employer's mail administrator reject me to correct it from the server. As his concern is, if ither ios devices works why don't mine? So I am helpless than changing my iphone. It works fine for early versions of ios and with androids. And also one of my friends iphone4 with ios 7 (similar as mine) works too. So I guess it's something wrong with my iPhones settings. But basic question I cannot understand is it works in my phone before this ios7 upgrading. And currently working with my yahoo account too. Favourable reply expected.

Query is allocating too large memory Error ( 4GB) in Essbase 11.1.2

Hi All,
Currently we are preparing dashboards in OBIEE from the Hyperion Essbase ASO (11.1.2) Cubes.When are trying to retrieve data with more attributes we are facing the below error
"Odbc driver returned an error (SQLExecDirectW).
Error Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 96002] Essbase Error: Internal error: Query is allocating too large memory ( > 4GB) and cannot be executed. Query allocation exceeds allocation limits. (HY000)"
Currently we have data file size less than 2GB so we are using "Pending Cache Size=64MB".
Please let me know which memory I have to increase to resolve this issue
Thanks,
SatyaB

Hi,
Do you have any dynamic hierarchies? What is the size of the data set?
Thanks,
Nathan

Time Machine Error - The backup is too large for the backup disk

I have been using Lion (currently 10.7.1) on my MacBook Pro (13" - early 2011) since it was released. I haven't had any serious problems with it.
All of a sudden, I am getting an error in Time Machine. When it tries to run a backup, the error "This backup is too large for the backup disk. The backup requires 7.51 GB but only 630.1 GB are available." What gives? That's plenty of room. I have installed Logic Studio and a few plug-ins, so the 7.51 GB is probably right. The free space is correct as well. I can't understand what the problem is.
The backup disk is an external USB 2.0 drive with no other Time Machine backups on it or any other files. The folder "Backups.backupdb" is the only thing on the root of the disk.
I am reluctant to reset the Time Machine and lose all of the backups, but I will if anyone recommends it.

Hi Linc,
It is not working at the moment, as I have restored the original Lion image again; it has all my work and apps on it.
Many thanks for the info on the log, though. It tells a strange story. Here's the log from the last backup that worked to the first one that failed: --
Sep 12 17:15:55 Johns-MacBook-Pro com.apple.backupd[674]: Starting standard backup
Sep 12 17:15:55 Johns-MacBook-Pro com.apple.backupd[674]: Backing up to: /Volumes/Backup/Backups.backupdb
Sep 12 17:15:55 Johns-MacBook-Pro com.apple.backupd[674]: 100.0 MB required (including padding), 633.72 GB available
Sep 12 17:15:55 Johns-MacBook-Pro com.apple.backupd[674]: Waiting for index to be ready (100)
Sep 12 17:16:00 Johns-MacBook-Pro com.apple.backupd[674]: Copied 793 files (601 KB) from volume System.
Sep 12 17:16:00 Johns-MacBook-Pro com.apple.backupd[674]: 100.0 MB required (including padding), 633.72 GB available
Sep 12 17:16:01 Johns-MacBook-Pro com.apple.backupd[674]: Copied 89 files (93 bytes) from volume System.
Sep 12 17:16:01 Johns-MacBook-Pro mds[34]: (Error) Volume: Could not find requested backup type:2 for volume
Sep 12 17:16:01 Johns-MacBook-Pro com.apple.backupd[674]: Starting post-backup thinning
Sep 12 17:16:01 Johns-MacBook-Pro com.apple.backupd[674]: Deleted /Volumes/Backup/Backups.backupdb/John’s MacBook Pro/2011-09-11-154229 (1.1 MB)
Sep 12 17:16:01 Johns-MacBook-Pro com.apple.backupd[674]: Post-back up thinning complete: 1 expired backups removed
Sep 12 17:16:01 Johns-MacBook-Pro com.apple.backupd[674]: Backup completed successfully.
Sep 13 10:34:12 Johns-MacBook-Pro com.apple.backupd[287]: Starting standard backup
Sep 13 10:34:12 Johns-MacBook-Pro com.apple.backupd[287]: Backing up to: /Volumes/Backup/Backups.backupdb
Sep 13 10:34:52 Johns-MacBook-Pro com.apple.backupd[287]: 7.51 GB required (including padding), 630.11 GB available
Sep 13 10:34:52 Johns-MacBook-Pro com.apple.backupd[287]: No expired backups exist - deleting oldest backups to make room
Sep 13 10:34:52 Johns-MacBook-Pro mds[32]: (Error) Volume: Could not find requested backup type:2 for volume
Sep 13 10:35:03 Johns-MacBook-Pro com.apple.backupd[287]: Backup failed with error: Not enough available disk space on the target volume.
I don't understand. For starters, I think it's a little wasteful that 3.5 GB has been used to back up 601 KB. That's the difference in free space on the backup volume between the two backups. That can't be normal, surely.
The only error is that mds[32] error, and from what I've read on forums, that seems to appear on backups that work perfectly.
Too weird. It looks like I'll have to reinstall Lion and all my applications again to get Time Machine working, or find another backup solution.

"ERROR: Could not read block 64439 of relation 1663/16385/16658: Result too large"

Hi,
I've already archived a lot of assets in my final cut server but since one week there is a message appearing when I click on an asset and choose "Archive". The pop-up says: "ERROR: Could not read block 64439 of relation 1663/16385/16658: Result too large"
Does anyone know what's the problem and/or have any suggestions to solve my problem?! I can't archive anymore since the first appearance of this message.
What happened before?
-> I archived some assets via FCS and then transfered the original media to an offline storage media. That system worked fine for the last months and my normal server stays quit small in storage use. But now, after I added some more new productions and let FCS generate the assets, it doesn't work anymore...
It's not about the file size - I tried even the smallest file I found in some productions.
It's not a particular production - I tried some different productions.
It's not about the storage - there's a lot of storage left on my server.
So, if someone knows how get this server back on the road - let me know.
THNX!
Chris

I would really appreciate some advice re: recent FCS search errors.
We're having similar issues to C.P.CGN's 2 year old post, it's only developed for us in the last few weeks.
Our FCS machine is running 10.6.8 mac os and 1.5.2 final cut server with the latest
OS 10.6.x updates.
FCS is still usable for 6 of 8 offliners, but on some machines, searching assets presents "ERROR: could not read block 74012 of relation1663/16385/16576: Input/output error."
Assuming the OS and/or data drives on the FCS machine were failing, I cloned the database drive today and will clone the OS drive tomorrow night, but after searching the forums and seeing similar error messages I'm not so sure.
FCS has been running fine for last 4 years, minus the recent Java security issues.
Thanks in advance, any ideas appreciated!
cheers,
Aaron Mooney,
Post Production Supervisor.
Electric Playground Daily, Reviews On The Run Daily, Greedy Docs.
epn.tv

Update trigger fails with value too large for column error on timestamp

Hello there,
I've got a problem with several update triggers. I've several triggers monitoring a set of tables.
Upon each update the updated data is compared with the current values in the table columns.
If different values are detected the update timestamp is set with the current_timestamp. That
way we have a timestamp that reflects real changes in relevant data. I attached an example for
that kind of trigger below. The triggers on each monitored table only differ in the columns that
are compared.
CREATE OR REPLACE TRIGGER T_ava01_obj_cont
BEFORE UPDATE on ava01_obj_cont
FOR EACH ROW
DECLARE
v_changed boolean := false;
BEGIN
IF NOT v_changed THEN
    v_changed := (:old.cr_adv_id IS NULL AND :new.cr_adv_id IS NOT NULL) OR
                 (:old.cr_adv_id IS NOT NULL AND :new.cr_adv_id IS NULL)OR
                 (:old.cr_adv_id IS NOT NULL AND :new.cr_adv_id IS NOT NULL AND :old.cr_adv_id != :new.cr_adv_id);
END IF;
IF NOT v_changed THEN
    v_changed := (:old.is_euzins_relevant IS NULL AND :new.is_euzins_relevant IS NOT NULL) OR
                 (:old.is_euzins_relevant IS NOT NULL AND :new.is_euzins_relevant IS NULL)OR
                 (:old.is_euzins_relevant IS NOT NULL AND :new.is_euzins_relevant IS NOT NULL AND :old.is_euzins_relevant != :new.is_euzins_relevant);
END IF;
[.. more values being compared ..]
    IF v_changed THEN
    :new.update_ts := current_timestamp;
END IF;
END T_ava01_obj_cont;Really relevant is the statement
:new.update_ts := current_timestamp;So far so good. The problem is, it works the most of time. Only sometimes it fails with the following error:
SQL state [72000]; error code [12899]; ORA-12899: value too large for column "LGT_CLASS_AVALOQ"."AVA01_OBJ_CONT"."UPDATE_TS"
(actual: 28, maximum: 11)
I can't see how the value systimestamp or current_timestamp (I tried both) should be too large for
a column defined as TIMESTAMP(6). We've got tables where more updates occur then elsewhere.
Thats where the most of the errors pop up. Other tables with fewer updates show errors only
sporadicly or even never. I can't see a kind of error pattern. It's like that every 10.000th update
or less failes.
I was desperate enough to try some language dependend transformation like
IF v_changed THEN
    l_update_date := systimestamp || '';
    select value into l_timestamp_format from nls_database_parameters where parameter = 'NLS_TIMESTAMP_TZ_FORMAT';
    :new.update_ts := to_timestamp_tz(l_update_date, l_timestamp_format);
END IF;to be sure the format is right. It didn't change a thing.
We are using Oracle Version 10.2.0.4.0 Production.
Did anyone encounter that kind of behaviour and solve it? I'm now pretty certain that it has to
be an oracle bug. What is the forum's opinion on that? Would you suggest to file a bug report?
Thanks in advance for your help.
Kind regards
Jan

Could you please edit your post and use formatting and tags. This is pretty much unreadable and the forum boogered up some of your code.
Instructions are here: http://forums.oracle.com/forums/help.jspa

"result too large" error when accessing files

Hi,
I'm attempting to make a backup copy of one of my folders (using tar from shell). For several files, I got "Read error at byte 0, reading 1224 bytes: Result too large" error message. It seems those files are unreadable. Whatever application attempts to access them results with the same error.
The files reside on the volume that I created a day ago. It's a non-journaled HFS+ volume on external hard drive. They are part of an Aperture Vault that I wanted to make an archive copy and store offsite. Aperture was closed (not running) when I was creating the archive.
This means two things. The onsite backup of my photos is broken, obviously (some of the files are unreadable). My offsite backup is broken, since it doesn't contain those files.
I've searched the net, and found couple of threads on some mailing lists describing same problem. But no answer. Couple of folks on those mailing lists suggested it migh point to full disk. However, in my case, there is some 450GB of free space on the volume I was getting read errors on (the destination volume had about 200GB free, and system drive had about 50GB free, so there was plenty of space all around the system too).
File system corruption?
Mac OS X (10.4.9)

Here's the tar command with the output:
$ tar cf /Volumes/WINNIPEG\;TOPORKO/MacBackups/2007-05-27/aperture.tar Alex\ -\ External\ HD.apvault
tar: Alex - External HD.apvault/Library/2003.approject/2007-03-24 @ 08\:17\:52 PM - 1.apimportgroup/IMG0187/Thumbnails/IMG0187.jpg: Read error at byte 0, reading 3840 bytes: Result too large
tar: Alex - External HD.apvault/Library/2006.approject/2007-03-24 @ 08\:05\:07 PM - 1.apimportgroup/IMG2088/IMG2088.jpg.apfile: Read error at byte 0, reading 1224 bytes: Result too large
tar: Alex - External HD.apvault/Library/Jasper and Banff 2006.approject/2007-03-25 @ 09\:41\:41 PM - 1.apimportgroup/IMG1836/IMG1836.jpg.apfile: Read error at byte 0, reading 1224 bytes: Result too large
tar: Alex - External HD.apvault/Library/Old Scanned.approject/2007-03-24 @ 12\:42\:55 AM - 1.apimportgroup/Image04_05 (1)/Info.apmaster: Read error at byte 0, reading 503 bytes: Result too large
tar: Alex - External HD.apvault/Library/Old Scanned.approject/2007-03-24 @ 12\:42\:55 AM - 1.apimportgroup/Image16_02/Info.apmaster: Read error at byte 0, reading 499 bytes: Result too large
tar: Alex - External HD.apvault/Library/Vacation Croatia 2006.approject/2007-03-25 @ 09\:47\:17 PM - 1.apimportgroup/IMG0490/IMG0490.jpg.apfile: Read error at byte 0, reading 1224 bytes: Result too large
tar: Error exit delayed from previous errors
Here's the "ls -l" output for one of the files in question:
$ ls -l IMG_0187.jpg
-rw-r--r-- 1 dijana dijana 3840 Mar 24 23:27 IMG_0187.jpg
Accessing that file (or any other from the above list) gives same/similar error. The wording differes from command to command, but basically it's the same thing (read error, or result too large, or both combined). For example:
$ cp IMG_0187.jpg ~
cp: IMG_0187.jpg: Result too large
The console log doesn't show any related errors.

Alter mount database failing: Intel SVR4 UNIX Error: 79: Value too large for defined data type

Hi there,
I am having a kind of weird issues with my oracle enterprise db which was perfectly working since 2009. After having had some trouble with my network switch (replaced the switch) the all network came back and all subnet devices are functioning perfect.
This is an NFS for oracle db backup and the oracle is not starting in mount/alter etc.
Here the details of my server:
- SunOS 5.10 Generic_141445-09 i86pc i386 i86pc
- Oracle Database 10g Enterprise Edition Release 10.2.0.2.0
- 38TB disk space (plenty free)
- 4GB RAM
And when I attempt to start the db, here the logs:
Starting up ORACLE RDBMS Version: 10.2.0.2.0.
System parameters with non-default values:
processes                = 150
shared_pool_size         = 209715200
control_files            = /opt/oracle/oradata/CATL/control01.ctl, /opt/oracle/oradata/CATL/control02.ctl, /opt/oracle/oradata/CATL/control03.ctl
db_cache_size            = 104857600
compatible               = 10.2.0
log_archive_dest         = /opt/oracle/oradata/CATL/archive
log_buffer               = 2867200
db_files                 = 80
db_file_multiblock_read_count= 32
undo_management          = AUTO
global_names             = TRUE
instance_name            = CATL
parallel_max_servers     = 5
background_dump_dest     = /opt/oracle/admin/CATL/bdump
user_dump_dest           = /opt/oracle/admin/CATL/udump
max_dump_file_size       = 10240
core_dump_dest           = /opt/oracle/admin/CATL/cdump
db_name                  = CATL
open_cursors             = 300
PMON started with pid=2, OS id=10751
PSP0 started with pid=3, OS id=10753
MMAN started with pid=4, OS id=10755
DBW0 started with pid=5, OS id=10757
LGWR started with pid=6, OS id=10759
CKPT started with pid=7, OS id=10761
SMON started with pid=8, OS id=10763
RECO started with pid=9, OS id=10765
MMON started with pid=10, OS id=10767
MMNL started with pid=11, OS id=10769
Thu Nov 28 05:49:02 2013
ALTER DATABASE   MOUNT
Thu Nov 28 05:49:02 2013
ORA-00202: control file: '/opt/oracle/oradata/CATL/control01.ctl'
ORA-27037: unable to obtain file status
Intel SVR4 UNIX Error: 79: Value too large for defined data type
Additional information: 45
Trying to start db without mount it starts without issues:
SQL> startup nomount
ORACLE instance started.
Total System Global Area 343932928 bytes
Fixed Size                  1280132 bytes
Variable Size             234882940 bytes
Database Buffers          104857600 bytes
Redo Buffers                2912256 bytes
SQL>
But when I try to mount or alter db:
SQL> alter database mount;
alter database mount
ERROR at line 1:
ORA-00205: error in identifying control file, check alert log for more info
SQL>
From the logs again:
alter database mount
Thu Nov 28 06:00:20 2013
ORA-00202: control file: '/opt/oracle/oradata/CATL/control01.ctl'
ORA-27037: unable to obtain file status
Intel SVR4 UNIX Error: 79: Value too large for defined data type
Additional information: 45
Thu Nov 28 06:00:20 2013
ORA-205 signalled during: alter database mount
We have already checked in everywhere in the system, got oracle support as well without success. The control files are in the place and checked with strings, they are correct.
Can somebody give a clue please?
Maybe somebody had similar issue here....
Thanks in advance.

Did the touch to update the date, but no joy either....
These are further logs, so maybe can give a clue:
Wed Nov 20 05:58:27 2013
Errors in file /opt/oracle/admin/CATL/bdump/catl_j000_7304.trc:
ORA-12012: error on auto execute of job 5324
ORA-27468: "SYS.PURGE_LOG" is locked by another process
Sun Nov 24 20:13:40 2013
Starting ORACLE instance (normal)
control_files = /opt/oracle/oradata/CATL/control01.ctl, /opt/oracle/oradata/CATL/control02.ctl, /opt/oracle/oradata/CATL/control03.ctl
Sun Nov 24 20:15:42 2013
alter database mount
Sun Nov 24 20:15:42 2013
ORA-00202: control file: '/opt/oracle/oradata/CATL/control01.ctl'
ORA-27037: unable to obtain file status
Intel SVR4 UNIX Error: 79: Value too large for defined data type
Additional information: 45
Sun Nov 24 20:15:42 2013
ORA-205 signalled during: alter database mount

File too large error or corrupt file error

I have scanned some images using a Nikon Cool Scan and when trying to import the the NEF files into Lightroom I get a corrupt or unrecognized file error. Bring it into CS2 or CS3 and save as TIFF and try the import and get a File too large error.
Any ideas or help on this. What is the file size max for import?
The scan is 4000dpi even tried at 300dpi.
Thanks in advance for any insight.

> Is it truly a size problem? If so, what is recommended? Lee Jay states that 10000 pixels is the max on either side. Okay, in DPI, what does that translate to?
 
 There's no necessary relationship between pixels and dots. You could scan an image at 4,000,000 dpi and translate it into an image of 100 x 100 pixels. I've used ridiculous extremes to make a point. The LR limitation is currently 10,000 pixels for any side. So you could have 9,000 x9,000 pixels but not 10,001 x50 pixels.
 
 Is this now clearer?
 
 
John "McPhotoman"
 color="#800000" size="2">~~ John McWilliams
 
 
 
 MacBookPro 2 Ghz Intel Core Duo, G-5 Dual 1.8;
 Canon DSLRs

Jrun error 413 header length too large

hi there,
is there any way to check where this error originates? any coldfusion logs etc?
error: jrun error 413 header length too large
it's giving me complete headache
cheers,
Simon

Hi Simon,
I am not entirely sure changing JVM is going to help however thought I would post some notes on how to do that.
Download from Oracle Java developer kit (not runtime):
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Java JDK 1.6.0_23 is current (note I have not trialled that one on CF9 very much yet).
Install that via running EXE you downloaded - default install will be fine.
Stop CF - SERVICES.msc stop "ColdFusion 9 Application Server".
Take a copy of CF\runtime\bin\jvm.config - so you got a backup.
Edit CF\runtime\bin\jvm.config find line "java.home=" and comment it out eg:
#java.home=C:/ColdFusion9/runtime/jre
Add new line like so and save jvm.config:
java.home=C:/Program Files/Java/jdk1.6.0_23/jre
Note there the slashes and the location of the JRE (runtime) - you need to point to the one in JDK because the other JRE in C:\Program Files\Java\jre6 will be missing a DLL.
Start CF via SERVICES.msc.
HTH, Carl.

Flarcreate error: too large to archive in current mode

Similar Messages

Maybe you are looking for