Index size increased after import

hi i mentioned already the index creation problem when i am trying to create index using script after import of table.So droped the table and created table using script and index also without data,then i started to import at tablelevel with indexes=n then ia m importing data from the production database.
The size of the 2 indexes in production is 750 and 1200 mb each in test db both index size increased around double 1200 and 1700 mb each.I used same script in both db.Why this is increased here i took the export with compress=y full database export.Why the index size increased? when i created the index with initial extent and next extent size respective 800 and 100 mb.Whether is it the reason?
with regards
ramya

i gave initial 1000 and next 100 for the index size around 1.1 gb in production but here in test why this became around 1.7 gb,eventhough the pct increase is 50 it should come around 1.3 maximum.Whether it will give any performance problem
wiht regards
ramya

Similar Messages

IPA size increasing after itunes connect upload

Hello,
it seems that the IPA size increases after upload to the AppStore: i have an 8Mo IPA (where near 80% is Air runtime), when it's uploaded to the AppStore i get a 21Mo file to download.

The IPA file you've made is really a zip file. The one from the app store is more of a package. If you rename your IPA to end as .zip, and uncompress that, what is the size of the app file that is inside the Payload folder? That's roughly the size the app store IPA will be.

Datafiles sizes increased while importing

Dears,
I need to import HR dump from database 1 into database 2. I knew how to do this but while importing, i faced some problems regarding to space issue in database 2.
I had to stop importing to increase space. after i did this , i repeated importing again but now i noticed that data files sizes in database 2 increased and import failed.
How can i rollback these data files sizes to previous size to can do importing successfully ?
Thanks & Regards,,

*Oracle DBA* wrote:
Dears,
I need to import HR dump from database 1 into database 2. I knew how to do this but while importing, i faced some problems regarding to space issue in database 2.
I had to stop importing to increase space. after i did this , i repeated importing again but now i noticed that data files sizes in database 2 increased and import failed.
How can i rollback these data files sizes to previous size to can do importing successfully ?
Thanks & Regards,,
Could you be more specific? I don't find "import failed" in my error message manual. I'm quite sure when "import failed" it gave you a more specific error message.

Index Size Increase (Rebuild with Parallel)

All,
I'm not sure whether or not this is an Exadata problem, but we saw it happen on our Exadata machine (maybe the larger extents are impacting this). However, I thought this forum might have an idea, especially if it’s a generic RDBMS issue instead of an Exadata one
I am running my Production EDW on an Exadata V2 quarter-rack running 11.2.0.2 BP7 RDBMS and GI and 11.2.2.3.2 ESS on OEL5.5
We have started to implement HCC compression due to space pressure. Last Thursday/Friday, we attempted to compress our largest table:
• 20bn rows, 3.7Tb in size, DEGREE 2, INSTANCE 1, 2555 partitions
• 8 bitmap partitioned indexes each with DEGREE 20, INSTANCE 1. Total size AFTER the rebuild: 1.3Tb (significantly greater than before!!)
• ‘Archive High’ HCC compression applied to the oldest 10% partitions (255).
• Remaining partitions were left uncompressed.
Because of the fact our biggest tables make use of bitmap indexes, in order for us to use HCC (which doesn’t like bitmaps), we had to:
• Disable all bitmap indexes
• Compress the oldest 10% of partitions with archive high HCC compression
• Rebuild the indexes for these partitions (255 total, 8 bitmap indexes each)
• Gather statistics
• Rebuild the indexes for the rest of the partitions (the remaining 90%). This took BY FAR the longest time.
During the last step, the index rebuilds seemed to take an excessive length of time – to rebuild all 8 bitmap indexes on one partition was about 3 minutes. This, obviously, had a big impact on the end users as this happens to be the table that most feeds hit (of course…!). We happened to run into the nightly batch too, which was as fantastic as you can probably imagine.
On Monday, we noticed that the tablespace for the indexes had ballooned by about 800Gb and figured out that the culprit was mainly the table’s indexes. Some index partitions had increased up to 20x (the degree of parallelism used to rebuild the index). Further research shows that we have seen this for other tables with varying results (if an index had DEGREE 8, we might see it increase by 8 times, etc).
We had the same issue in our Development environment as well. When we rebuilt the same indexes in Development (and Production) with no parallelism (DEGREE 1), we were able to rebuild 6 entire partitions (with 8 indexes each) in less than one minute: an 18x performance improvement. I suspect that the underlying table having DEGREE 2 allowed it to use the SmartScan, but still.
Obviously, increasing the index size by 20x was not meant to be part of the HCC compression results. We’ve saved 3.1Tb in total with HCC, but we have increased the size of the indexes just on this one table alone by 1Tb! However, we also saw this happen on index partitions which had NOT been compressed by HCC – which seems to rule out HCC being a factor in this (probably?)
We have seen this on another table which is partitioned with bitmap indexes. However, we only saw this increase in those indexes which had DEGREE >1. There were two other indexes on that table which were serial and saw NO increase in space usage.
I don’t know whether we see this because of…
• bitmap indexes
• bitmap partitioned indexes
• indexes on partitioned tables
• tables which use SmartScan
• HCC
• Exadata
• 11.2
• Larry Ellison hates me and wants to make my life miserable by introducing random errors just to annoy me
• All/any/none of the above
This sounds like it’s a bug to me with the indexes being parallelized. Anyone else seen this happen?
Any ideas, advice, jokes, cash appreciated...
Mark

The thing that makes me doubt it's related to the default partition size is that if we rebuild the indexes serially, the size is reduced by orders of magnitude. I do think it's somewhere in that ball park, though...
I'm not sure if this isn't related to Exadata - the default extent size is 4Mb (and we haven't changed that). For eight bitmap indexes, that means the initially allocated extents (we don't defer) for just one partition total 32Mb.
Yes, sorry, by 'ballooning by Monday morning', I was using some poetic license. The reason being that we actually lost a disk on the Thursday morning and replaced it on Thursday evening. Obviously, that masked the amount of usable space until the disk had re-balanced. The 'ballooning' has been definitively proven to be related to the degree of parallelism.
Our plan is to create the indexes serially - after all, it doesn't appear that parallelism speeds up their rebuilds during the batch (which is why they were set so high originally). First of all, I have to persuade certain power users to accept the reduction in parallelism at the object-level (not a best practice, anyway) and get them to use optimizer hints in their queries. I've been fighting this fight for a while because users can inadvertently consume ridiculous amounts of parallel slaves and compromise the stability of the system.
I will check the extents - previously, I had just been querying segment usage by partition. Maybe the extents might help pinpoint the cause...

Index size increases than table size

Hi All,
Let me know what are the possible reasons for index size greater than the table size and in some cases index size smaller than table size . ASAP
Thanks in advance
sherief

hi,
The size of a index depends how inserts and deletes occur.
With sequential indexes, when records are deleted randomly the space will not be reused as all inserts are in the leading leaf block.
When all the records in a leaf blocks have been deleted then leaf block is freed (put on index freelist) for reuse reducing the overall percentage of free space.
This means that if you are deleting aged sequence records at the same rate as you are inserting, then the number of leaf blocks will stay approx constant with a constant low percentage of free space. In this case it is most probably hardly ever worth rebuilding the index.
With records being deleted randomly then, the inefficiency of the index depends on how the index is used.
If numerous full index (or range) scans are being done then it should be re-built to reduce the leaf blocks read. This should be done before it significantly affects the performance of the system.
If index access’s are being done then it only needs to be rebuilt to stop the branch depth increasing or to recover the unused space
here is a exemple how index size can become larger than table size:
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as admin
SQL> create table rich as select rownum c1,'Verde' c2 from all_objects;
Table created
SQL> create index rich_i on rich(c1);
Index created
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1179648 144 9
INDEX 1179648 144 9
SQL> delete from rich where mod(c1,2)=0;
29475 rows deleted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1179648 144 9
INDEX 1179648 144 9
SQL> insert into rich select rownum+100000, 'qq' from all_objects;
58952 rows inserted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1703936 208 13
INDEX 2097152 256 16
SQL> insert into rich select rownum+200000, 'aa' from all_objects;
58952 rows inserted
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 2752512 336 21
INDEX 3014656 368 23
SQL> delete from rich where mod(c1,2)=0;
58952 rows deleted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 2752512 336 21
INDEX 3014656 368 23
SQL> insert into rich select rownum+300000, 'hh' from all_objects;
58952 rows inserted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 3014656 368 23
INDEX 4063232 496 31
SQL> alter index rich_i rebuild;
Index altered
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 3014656 368 23
INDEX 2752512 336 21
SQL>

DB Size increase after calculation

When I calculate my DB its size increases abnormaly. If I export all the data and import it again, the DB size shrinks to 50% of its former size. Why does that happen?Dimensions:Time (Dense)Measures (Dense)Organization (Sparse)Products(Sparse)Value Type (Sparse) VT_CHF VT_EUR FX_EURMy calc script is:(IF(VT_CHF<>0 AND VT_CHF<>#MISSING)VT_EUR = VT_CHF/MEA_DUMMY->ORG_DUMMY->PROD_DUMMY->FX_EUR;ENDIF;)

This usually happens if you have committed access on. Your database can effectively double in size because when a block is calculated, a new block is created and then the pointer is changed from the old block to the new one. The old blocks stay in your pag file. To fix this, I changed to uncommitted access and then set a number in the commit blocks field to represent the number of blocks of redundant data that the database will retain. The higher the number, the more your database will grow, but a low number will impact on calc times if the block sizes are small.

File size changes after importing photos

Quick question here. I've been using iphoto (now using iphoto 8)for a couple years and just noticed that after importing photos (I use a variety of original formats, usually jpeg or raw) the file size in iphoto is a lot smaller than the original (roughly half). First of all, why is this? Is there any way for iphoto to retain the original size? If I try copying a photo out of iphoto, say onto my desktop, the file size remains the same as it was in iphoto. In other words, it doesn't revert back to the original.
Any idea as to why it would do this?
Some help would be much appreciated.
Ads

Welcome to the Apple Discussions. When a raw file is imported iPhoto creates a jpg version so if you're looking at that and comparing to the size of the raw file, yes it will be smaller.
If you edit a photo the resulting file will be slightly smaller since there will be one level of jpeg compression added to the file. All subsequent edits will not cause any more compression because the edit instructions are saved in the database file and applied to the file for viewing, printing and exporting. That's why iPhoto calls it nondestructive editing.
If the photo is portrait oriented and comes from a camera which has the auto-rotate feature iPhoto will create a rotated version and that will contain some jpeg compression.
Dragging the photo to the desktop will bring the edited version which will be smaller. To get the original file export using the Format=Original setting as Larry has already pointed out.
If you're worried about image quality unless you will be printing a very large photo you'll be hard pressed to see any degradation in the image.
TIP: For insurance against the iPhoto database corruption that many users have experienced I recommend making a backup copy of the Library6.iPhoto (iPhoto.Library for iPhoto 5 and earlier versions) database file and keep it current. If problems crop up where iPhoto suddenly can't see any photos or thinks there are no photos in the library, replacing the working Library6.iPhoto file with the backup will often get the library back. By keeping it current I mean backup after each import and/or any serious editing or work on books, slideshows, calendars, cards, etc. That insures that if a problem pops up and you do need to replace the database file, you'll retain all those efforts. It doesn't take long to make the backup and it's good insurance.
I've created an Automator workflow application (requires Tiger or later), iPhoto dB File Backup, that will copy the selected Library6.iPhoto file from your iPhoto Library folder to the Pictures folder, replacing any previous version of it. There are versions that are compatible with iPhoto 5, 6, 7 and 8 libraries and Tiger and Leopard. Just put the application in the Dock and click on it whenever you want to backup the dB file. iPhoto does not have to be closed to run the application, just idle. You can download it at Toad's Cellar. Be sure to read the Read Me pdf file.
NOTE: iPhoto 8's new option in it's rebuild library window, "Rebuild the iPhoto Library Database from automatic backup" may make this tip obsolete. We'll know when users have occasion to use it and see if that's the case.

Why are frame sizes increasing after editing with Nik plug-ins?

I’m using the Nik Collection of plug-ins with Aperture, and have discovered that the frame size of the resulting edits always end up larger than the original - sometimes much larger.
The original image starts as 4592 x 3448 but after editing, the longest side of the resulting image is typically over 5000, 6000 or even 7000 pixels.
I recently worked on a cropped image that started at 4138 x 2759 and ended up at 7361 x 4908, after editing with a combination of Dfine, Viveza, Color Efex + Silver Efex. If I export a version during the editing process, and then carry out futher editing, the frame size increases again.
I’m exporting from Aperture using the TIFF - Original Size (16 bit) setting.
Can anyone tell me what’s going on here? I’m concerned that the quality of the images is being compromised by the enlargement.
I'm using the latest set of Nik plug-ins, with Aperture 3.2.4 on a MBP running 10.6.8

Keli
In order to open Aperture in 32-bit mode by default you can right-click on the application icon, select "Get Info" and check the box marked "Open In 32-bit Mode" (or you can continue to run it by default in 64-bit mode and just get forced to re-open the app anytime you need to use plug-ins that can only run in 32-bit mode).
hope this helps!
Raf

IPhoto 9.5.1 cannot locate photos I imported...but the size of my iPhoto folder has definitely increased after importing - help!

I imported over 40GB of photos into iPhoto but now when I go to view there is a thumbnail but I receive an Alert message about not finding the original after I click on it.
The iPhoto folder definitely increased in size after the importing. I'm running iPhoto 9.5.1.
Thanks!

Option 1
Back Up and try rebuild the library: hold down the command and option (or alt) keys while launching iPhoto. Use the resulting dialogue to rebuild. Choose to Repair Database. If that doesn't help, then try again, this time using Rebuild Database.
If that fails:
Option 2
Download iPhoto Library Manager and use its rebuild function. (In early versions of Library Manager it's the File -> Rebuild command. In later versions it's under the Library menu.)
This will create an entirely new library. It will then copy (or try to) your photos and all the associated metadata and versions to this new Library, and arrange it as close as it can to what you had in the damaged Library. It does this based on information it finds in the iPhoto sharing mechanism - but that means that things not shared won't be there, so no slideshows, books or calendars, for instance - but it should get all your events, albums and keywords, faces and places back.
Because this process creates an entirely new library and leaves your old one untouched, it is non-destructive, and if you're not happy with the results you can simply return to your old one.
Regards
TD

Mailbox size increased after removing attachments

Doing a little clean-up on my mail, I noticed my sent mailbox was 1.23 gigs. So, I went in saved several hundred attachments and then tried to remove attachments. It would only let me remove attachments about 5 messages at a time, so I moved over 300 messages that all had attachments to a new folder. After moving them I was able to remove all the attachments at one time.
But after moving and removing attachments the size of my sent mailbox did not decrease it actually increased by over 400 megs to 1.7 gigs. And the new folder was also very large, at almost 700 megs (even after removing attachments).
Any ideas how/why this happens? and what can I do to reduce the size of that mailbox?
I have had the overflow issue before and have been trying to keep and eye on the mailbox sizes and keep them under 1 gig, but this one got by me. My only complaint is mail does not tell you the size of a mailbox in the application, if I was able to check the mailbox size right from the app it would be an easier thing to keep an eye on an everyday basis.
Any help would be great.. thanks!
G4 400 Mac OS X (10.3.9)

For each mailbox, Mail 1.x stores messages sequentially in an mbox file within the *.mbox package associated with the mailbox -- you can see the files contained in an *.mbox package by ctrl-cliking on it in the Finder and choosing Show Package Contents from the contextual menu.
When a message is removed from a mailbox in Mail 1.x, the actual message may be completely erased from the mbox file, or it may remain there just marked for deletion in one of the other supporting files within the *.mbox package. In order to reduce the mailbox size when a message is deleted from the middle, the entire mailbox would have to be rewritten to disk every time, which is clearly not practical.
When attachments are removed from a message, the attachments aren’t actually removed from anywhere. What really happens is that Mail creates a new message without the attachments and deletes the original message... and now you know what it really is that actually happens when a message buried in the middle of the mailbox is deleted...
My only complaint is mail does not tell you the size of a
mailbox in the application
Mail 1.3 sure does. The size of the selected mailbox is displayed in the status bar (View > Show Status Bar). Interestingly enough, that feature is no longer available in Mail 2.x.

I am having an issue with video file size increasing after editing in iMovie 11

So I start off my iMovie 11 video project with a .mp4 video file of roughly 900MB. After chopping off the beginning and ending (which is all I want to do) I have attempted finalizing and exporting using numerous options. The problem is, each time I do this my file turns into a 3.9GB .mov file! I don't want a huge file, I don't want a changed format file. I simply want to cut off the beginning and ending of my movie and leave everything else the same. Theoretically, this should make the file SMALLER since I am removing footage. Correct?
As you can probably tell, I am new to all this. But can anyone tell me how to keep my .mp4 file extension and simply delete the start and end?
Thanks!

The simple answer is, Don't Use iMovie.
If you want to just trim off pieces you can do that in QuickTime X, which is already installed on your Mac. Open the movie in the QuickTime X player. Now go to the Edit Menu and choose Trim... At the bottom of the window you will see a series of thumbnail images with a yellow highlighted box around it. To cut off the beginng pull in the handle along the left hand side of the yellow box. Same is true for the end grab the yellow handle on the right side and pull it in as well. Then click the Trim button, now you've got just the piece of the video you want to save. Now go to File > Save As... set the Format to be Movie (to keep it in the same file format as it started as.
This avoids all the transcoding/conversion that goes on when you import a video into iMovie.

File size increase after installing LCD ES v8.2.1 (CS3.3)

Hi, Problem: The file size of a LCD v8.0 form increases significantly when opened + saved in LiveCycle Designer ES v8.2.1. A Dynamic XML form, targeted at Reader 7 & up, build in LiveCycle Designer 8.0.?, has a file size of 75 kB. Our company has upgraded to Creative Suite 3.3, which is shipped with Acrobat Pro 9.0, and, apparently, LiveCycle Designer ES v8.2.1. The installation removes the previous version of LCD. If I just open and save the form in this new LCD, the file size becomes 473 kB. The XML-tab shows some additional rows, in the <config> part, but not enough for 400kB of extra code. Further specs: - Windows XP Pro SP3, fully patched; - Creative Suite 3.3, updated. Anyone a solution, work-around, some info?

SOLVED!
Don't embed fonts...
I was too hasty.
(did'nt even know you could embed the fonts in LCD)

Why does canvas size increase after shadow applied to image?

PE5 - Why does the canvas size of my project increase every time I apply drop-down shadow to a photo layer? I can re-size the canvas with no problem, but it keeps "growing" with each time I apply the effect. Photos are not near the margin of the canvas.

Not sure what you mean... it is a transparent 11x4 canvas and the layer above it contains an image that is 1 inch high ...other layers with the same size images are also present, but none are locked or "merged" (forgot the term used with PE) with the canvas...

SQL Developer:Problem with multi byte size after import using excel format

Hi,
Need your help. I am trying to export multibyte characters from our China instance(r11i instance) using SQL Developer's export data via Excel format into an R12 Vision instance. I have a staging table with exactly the same structure in both instances. Prior to export to excel, I check the byte size of the sample data below using LENGTH and LENGTHB sql functions and these are the results:
Sample data = 材料LI（USD）
LENGTH=9
LENGTHB=13
Then, I exported the table as excel file. Afterwards, I used SQL Developer to import the excel file into the table of the target instance. I check the bytesize again and here are the results:
Sample data = 材料LI（USD）
LENGTH=9
LENGTHB=17
The byte size increased from 13 to 17. I did not change anything on the excel file. Just straight forward export to excel file then imported it to the target instance. How come there is an increase in byte size? Has anyone encountered this in SQL Developer? We really need to export the files as excel.
Source:
Database version = 9.2.0.5.0
Target:
Database version = 11.1.0.7.0
Regards,
Wendell
Edited by: user13038177 on May 13, 2010 9:05 PM
Edited by: user13038177 on May 13, 2010 9:06 PM

Wendell,
This forum is for handling issues migrating from non-Oracle databases to Oracle databases.
As this is an Oracle to Oracle issue using SQL*Developer export it would be better to open a new thread in the SQL*Developer forum -
SQL Developer
There will be more people there who can help with this problem.
Regards,
Mike
Edited by: mkirtley on May 14, 2010 10:16 AM

Table index size in DB02 smaller after upgrade

SAP ERP 6.0, DB2 9.5, AIX 5.3. After we upgraded to SPS 15 / EHP4 / Netweaver EHP1 SPS02 using the downtime minimized method (shadow instance created) the index sizes for the tables are showing reduced sizes. When looking in DB02 under History -> "tables and indexes" all the tables show a drop in index sizes. I have compared the indexes to a pre upgrade copy of the system and all the indexes are still defined and active in the upgrades system. Can somebody please explain why the size drop? Is this a reporting error or what?

Hi Eddie,
DB2 V8.2 did not allow to retrieve table/index size information from DB2 directly. Therefore the SAP DB2 database interface and the CCMS code tried to do some size estimation based on cardinality and table/index width. DB2 V9.1+ provides table function ADMIN_GET_TAB_INFO to retrieve size information directly from DB2. Since this size information is much more accurate the SAP DB2 database interface and the CCMS code have been changed to use this table function.
So the phantom-"shrink" you observed may be related to the switch from size estimation to the size retrieved from ADMIN_GET_TAB_INFO . This may have happened directly after the V9.5 upgrade ( size retrieved differently in SAP DB2 database interface ) or after the SAP release upgrade ( change in CCMS ABAP coding ).
Regards
Frank

Index size increased after import

Similar Messages

Maybe you are looking for