"Invalid segment" when shrinking a partitioned table

I'm encountering the following error when trying to shrink space compact for a partitioned table. Would you know how can I go about this?
I need to make it work.
SQL> alter table PS_SGSN_1_MONTH modify partition P_201304 shrink space compact;
alter table PS_SGSN_1_MONTH modify partition P_201304 shrink space compact
ERROR at line 1:
ORA-10635: Invalid segment or tablespace type
My Oracle DB version is 11gR2

Yes, that would be the right thing to do to check how and where MV is being used and what downtime you can get to fix this. Check if you can change the Materialized view to create based on primary key instead of Row id.
Steps would be
1 drop the materialized views related
2 drop the materialized views logs
3 shrink the tables and indexes
4 recreate the materialized views log
5 recreate the materialized views
Also, there is a bug with the primary key as well. Check this
Bug 13709220 - ORA-10663 when shrinking a master table of an MVIEW with primary key (Doc ID 13709220.8)

Similar Messages

How to identity segment when to setup partition for large table?

I have a table with size is about 3G. There is a code column in this table with distinguish 20 value. I am try to create list partition on this column. How can I assign segment for different value for this partition?In my database, only less than 10 segments available. If I want the better performance, each partition should be on different segment or different device? Sould each sement have enough size to hold all data? what happen if the segment is smaller? for example, if I honly have 4 sgements each with 500M?
If I remove or change the strategy of partition, for example, change the type to range, if the system can release the partitions on segment automatically?

This section of the performance and tuning guide addresses all of these concerns. Give it a good read and post questions that you have about the documentation:
http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00841.1570/html/phys_tune/title.htm

ORA-00604 ORA-00904 When query partitioned table with partitioned indexes

Got ORA-00604 ORA-00904 When query partitioned table with partitioned indexes in the data warehouse environment.
Query runs fine when query the partitioned table without partitioned indexes.
Here is the query.
SELECT al2.vdc_name, al7.model_series_name, COUNT (DISTINCT (al1.vin)),
al27.accessory_code
FROM vlc.veh_vdc_accessorization_fact al1,
vlc.vdc_dim al2,
vlc.model_attribute_dim al7,
vlc.ppo_list_dim al18,
vlc.ppo_list_indiv_type_dim al23,
vlc.accy_type_dim al27
WHERE ( al2.vdc_id = al1.vdc_location_id
AND al7.model_attribute_id = al1.model_attribute_id
AND al18.mydppolist_id = al1.ppo_list_id
AND al23.mydppolist_id = al18.mydppolist_id
AND al23.mydaccytyp_id = al27.mydaccytyp_id
AND ( al7.model_series_name IN ('SCION TC', 'SCION XA', 'SCION XB')
AND al2.vdc_name IN
('PORT OF BALTIMORE',
'PORT OF JACKSONVILLE - LEXUS',
'PORT OF LONG BEACH',
'PORT OF NEWARK',
'PORT OF PORTLAND'
AND al27.accessory_code IN ('42', '43', '44', '45')
GROUP BY al2.vdc_name, al7.model_series_name, al27.accessory_code

I would recommend that you post this at the following OTN forum:
Database - General
General Database Discussions
and perhaps at:
Oracle Warehouse Builder
Warehouse Builder
The Oracle OLAP forum typically does not cover general data warehousing topics.

Reduce redo when shrinking a large partitioned LOB table?

Hi,
Oracle 10.2.0.5 - Solaris 10 - Dataguard
We have a large (30 Tb) partitioned table with two columns ID and BODY. This is range partitioned on ID, and hash subpartitioned with a million records per range partition and between 500Gb and 1Tb data per partition.
We never modify the LOB, but do delete around 40% over time. After a partiton is full (the ID sequence is greater than the partition value) this becomes read only data. Due to this pattern of partitioning, the space freed by delete is often not used by other inserts.
Looking at one of the partitions (one partition = one tablespace) we have a datafile size of 1100 Gb, segment size of 1095Gb, and a DBMS_LOB.GETLENGTH of 370Gb - so 725Gb "free space"
While we can use something like
alter table test_lob modify partition p1 lob (body) (shrink space cascade);
This generates a lot of redo which we then have to move to the standby and apply.
What other methods could be used to reclaim this space with reduced / no redo?
Thanks
Mark

Fran,
As I said we're using Dataguard - so force logging. I'm looking for an approach that avoids the redo generation, rather than just turns it off.
I'm currently wondering if swapping partitons and transportable tablespaces may work so I can do the work in a non dataguard database, then swap it back in and just copy that datafile across. The data is read only now.

Error ORA-10635 when shrink a table!!

Hi all,
I have a table created in a tablespace using ASSM and when i try to shrink this table i receive the error ORA-10635. I can do shrink on other tables that are on the same tablespace of that table that is giving me this error.
Anyone can help please??
Tks,
Paulo.

10635, 00000, "Invalid segment or tablespace type"
// *Cause: Cannot shrink the segment because it is not in auto segment space
// managed tablespace or it is not a data, index or lob segment.
// *Action: Check the tablespace and segment type and reissue the statement

Partition Pruning on Interval Range Partitioned Table not happening when SYSDATE used in Where Clause

We have tables that are interval range partitioned on a DATE column, with a partition for each day - all very standard and straight out of Oracle doc.
A 3rd party application queries the tables to find number of rows based on date range that is on the column used for the partition key.
This application uses date range specified relative to current date - i.e. for last two days would be "..startdate > SYSDATE -2 " - but partition pruning does not take place and the explain plan shows that every partition is included.
By presenting the query using the date in a variable partition pruning does table place, and query obviously performs much better.
DB is 11.2.0.3 on RHEL6, and default parameters set - i.e. nothing changed that would influence optimizer behavior to something unusual.
I can't work out why this would be so. It very easy to reproduce with simple test case below.
I'd be very interested to hear any thoughts on why it is this way and whether anything can be done to permit the partition pruning to work with a query including SYSDATE as it would be difficult to get the application code changed.
Furthermore to make a case to change the code I would need an explanation of why querying using SYSDATE is not good practice, and I don't know of any such information.
1) Create simple partitioned table
CREATETABLE part_test
   (id                      NUMBER NOT NULL,
    starttime               DATE NOT NULL,
    CONSTRAINT pk_part_test PRIMARY KEY (id))
PARTITION BY RANGE (starttime) INTERVAL (NUMTODSINTERVAL(1,'day')) (PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2013','DD-MM-YYYY')));
2) Populate table 1million rows spread between 10 partitions
BEGIN
    FOR i IN 1..1000000
    LOOP
        INSERT INTO part_test (id, starttime) VALUES (i, SYSDATE - DBMS_RANDOM.value(low => 1, high => 10));
    END LOOP;
END;
EXEC dbms_stats.gather_table_stats('SUPER_CONF','PART_TEST');
3) Query the Table for data from last 2 days using SYSDATE in clause
EXPLAIN PLAN FOR
SELECT count(*)
FROM    part_test
WHERE   starttime >= SYSDATE - 2;
| Id | Operation                 | Name      | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT          |           |     1 |     8 | 7895 (1)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE           |           |     1 |     8 |            |          |       |       |
|   2 |   PARTITION RANGE ITERATOR|           |   111K|   867K| 7895   (1)| 00:00:01 |   KEY |1048575|
|* 3 |    TABLE ACCESS FULL      | PART_TEST |   111K|   867K| 7895   (1)| 00:00:01 |   KEY |1048575|
Predicate Information (identified by operation id):
   3 - filter("STARTTIME">=SYSDATE@!-2)
4) Now do the same query but with SYSDATE - 2 presented as a literal value.
This query returns the same answer but very different cost.
EXPLAIN PLAN FOR
SELECT count(*)
FROM part_test
WHERE starttime >= (to_date('23122013:0950','DDMMYYYY:HH24MI'))-2;
| Id | Operation                 | Name      | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT          |           |     1 |     8 |   131 (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE           |           |     1 |     8 |            |          |       |       |
|   2 |   PARTITION RANGE ITERATOR|           |   111K|   867K|   131   (0)| 00:00:01 |   356 |1048575|
|* 3 |    TABLE ACCESS FULL      | PART_TEST |   111K|   867K|   131   (0)| 00:00:01 |   356 |1048575|
Predicate Information (identified by operation id):
   3 - filter("STARTTIME">=TO_DATE(' 2013-12-21 09:50:00', 'syyyy-mm-dd hh24:mi:ss'))
thanks in anticipation
Jim

As Jonathan has already pointed out there are situations where the CBO knows that partition pruning will occur but is unable to identify those partitions at parse time. The CBO will then use a dynamic pruning which means determine the partitions to eliminate dynamically at run time. This is why you see the KEY information instead of a known partition number. This is to occur mainly when you compare a function to your partition key i.e. where partition_key = function. And SYSDATE is a function. For the other bizarre PSTOP number (1048575) see this blog
http://hourim.wordpress.com/2013/11/08/interval-partitioning-and-pstop-in-execution-plan/
Best regards
Mohamed Houri

How to move lob segment in partitioned table

On my Oracle 11.2, I have a partitioned table wich I would like to move to another tablespace
After invoking script, there's still unmoved lob segment withing table
CREATE TABLE BONGO.AAA_3
ID       NUMBER,
DATUM    DATE,
OBJEKAT BLOB
TABLESPACE BONGODATA_HUGE
PCTUSED    40
PCTFREE    10
INITRANS   1
MAXTRANS   255
LOGGING
PARTITION BY RANGE (DATUM)
PARTITION P_MAXVALUE VALUES LESS THAN (MAXVALUE)
    LOGGING
    NOCOMPRESS
    TABLESPACE BONGODATA_HUGE
LOB (OBJEKAT) STORE AS
        (   TABLESPACE BONGODATA
          ENABLE        STORAGE IN ROW
          CHUNK       8192
          RETENTION
          NOCACHE
          STORAGE    (
                      INITIAL          64K
                      NEXT             1M
                      MINEXTENTS       1
                      MAXEXTENTS       UNLIMITED
                      PCTINCREASE      0
                      FREELISTS        1
                      FREELIST GROUPS 1
                      BUFFER_POOL      DEFAULT
    PCTUSED    40
    PCTFREE    10
    INITRANS   1
    MAXTRANS   255
    STORAGE    (
                INITIAL          64K
                NEXT             1M
                MINEXTENTS       1
                MAXEXTENTS       UNLIMITED
                FREELISTS        1
                FREELIST GROUPS 1
                BUFFER_POOL      DEFAULT
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;how to move this lob segment in partitioned table?
or, is there some package for data move within tablespaces?
regards

tnx...
now, I have another problem..
I have a nested table within partitioned table, and I'm trying to move it to another tablespace.
I tried to move child table (of nested type colum), but I didn't succedeed...

Jumpstart: Fdisk Partition Table Invalid

Hi,
I'm jumpstarting a Sun server with Solaris 10.
But during the jumpstart I received the next error:
Error: fdisk partition table invalid (c0t1d0)
Has someone an idea how I can fix this?

the previous jumpstart code would overwrite the entire disk.
what if i just want to fresh install (initial_install) the already existing Solaris partition.
The following jumpstart profile produce the same error message : "ERROR: fdisk partition table invalid" :
install_type initial_install
fdisk rootdisk solaris maxfree
pool root_pool auto 4g 4g rootdisk.s0
...Here is the console log :
Processing profile
        - Saving Boot Environment Configuration
        - Selecting cluster (SUNWCall)
       - Selecting geographic region (N_America)
        - Selecting geographic region (S_Europe)
        - Selecting geographic region (W_Europe)
        - Selecting geographic region (N_Europe)
        - Selecting geographic region (E_Europe)
        - Selecting geographic region (C_Europe)
        - Selecting all disks
        - Configuring boot device
        - Using disk (c1d0) for "rootdisk"
        - Creating "maxfree" Solaris fdisk partition (c1d0)
        - Using existing Solaris fdisk partition (c1d0)
ERROR: fdisk partition table invalid (c1d0)
ERROR: System installation failed
Solaris installation program exited.
...Note that fdisk is able to read the partitions :
fdisk -W - /dev/rdsk/c1d0p0
* /dev/rdsk/c1d0p0 default fdisk table
* Dimensions:
*    512 bytes/sector
*     63 sectors/track
*    255 tracks/cylinder
*   30400 cylinders
* systid:
* Id    Act Bhead Bsect Bcyl    Ehead Esect Ecyl    Rsect       Numsect
6     128 1         1        0         254      63      6        63            112392
7     0     0         1        7          254      63     1023    112455     102414375
191 0    254      63       1023    254      63     1023    102526830 102382245
15    0    254      63       1023    254     63      1023    204909075 283482990

HT5225 "This disc does not use the GUID Partition Table Scheme...". I keep getting this message when I try to install OSXLion. It has something to do with a repair Apple performed last year. I use a 17" MacBookPro. Any suggestions?

"This disc does not use the GUID Partition Table Scheme. Use Disc Utility to change the partition scheme". I keep getting this message when I try to install OSX Lion so that I can upgrade my 17" MacBookPro to move to iCloud. My harddrive was replaced last year by Apple because of a fault by the manufacturer and I think this is the cause of the problem. What can I do so that I don't lose my content.

When you click the partion tab. There is option on the bottom of the window. Click on that there there are these options.

Getting a Invalid Partition Table! message

Getting this message: Invalid Partition Table! after I ran a Windows Update downloads and install. My laptop is looping in start up. Not able to press F(, because the function is not activated. Anyway, I am not able to make a repair. The only thing I'm able
to run is the DOS-promt. And I can find this OS drive (C:\). I tested the SSHD with succes.
How did this happen? And how to solve this problem without a reinstall of Windows?

Do you have a Windows 8.1 media or a bootable USB drive?If then you can repair Start up/MBR.
Insert the Windows 8 Installation Disc in your system’s optical drive/a bootable USB
Select Repair option.
Choose Troubleshoot > Advanced.
From Advanced option,launch Command Prompt.
Enter the following command:
bootrec.exe /fixmbrReboot after the completion of the above command.
S.Sengupta, Windows Entertainment and Connected Home MVP

Compression getting disabled when performing Update on partitioned tables

Hi All,
I am on Oracle Database 11g Enterprise Edition Release 11.2.0.3.0.
My question is related to Oracle Compression.
I have a sub-partitioned table enabled with Basic Compression. In enabled compressed state, I am updating few columns of this table(Normal Update command and Merge as well) but the end result shows increase in the table size and the compression is still in ENABLED state. Post that, if I compress the sub-partition explicitly the table comes back to its original size.
Is it a bug? I read a white paper on 11g itself, that compression remains enabled in case of all DML operations, then why this behaviour?
Thanks,
Ishan

Ishan,
taking a look at http://docs.oracle.com/cd/E11882_01/server.112/e25494/tables.htm#CJAGFBFG It seems that the distinction between OLTP and basic compression is sometimes a little bit vague ("Operations that permit compression include: ..."), but I can also find the statement "Rows inserted without using direct-path insert and updated rows are uncompressed." So I would say it's not a bug but a limitation of the feature. Updates just don't mix well with compression.
Martin

When to create index on partitioned table ?

Hi,
The original table TEST1 contain one index called INDX_HIREDATE on field HIREDATE
CREATE TABLE TEST1(
COD NUMBER PRIMARY KEY,
HIREDATE DATE);
CREATE INDEX INDX_HIREDATE ON TEST1 (HIREDATE);
I created a example partitioned table as below:
CREATE TABLE TEST2_PART(
COD NUMBER PRIMARY KEY,
HIREDATE DATE)
PARTITION BY RANGE (HIREDATE)(
PARTITION P2003 VALUES LESS THAN (TO_DATE('01/01/2004','DD/MM/YYYY')),
PARTITION P2004 VALUES LESS THAN (TO_DATE('01/01/2005','DD/MM/YYYY')),
PARTITION P3000 VALUES LESS THAN (MAXVALUE));
INSERT /*+ APPEND */ INTO TEST2 SELECT * FROM TEST1;
Questions:
Need i to create the index on TEST2 table the same way done on the TEST1 table?
ex: CREATE INDEX INDX_HIREDATE ON TEST2 (HIREDATE);
or have i need to create the global/local index on each partition?
The Primary Key index is a global for partitions??
What is the best way?
Thanks

Index creation on partitioned tables is similar to the non-partitioned tables. There is no special syntax unless you need to create LOCAL indexes. For creating local indexes, add LOCAL key word at the end of the "create index...." command.
To create local primary key index you may need to use different syntax the one used in your create table command. Refer to SQL Reference manual for actual syntax. (remember manuals are the best place for getting quick answers). All the manuals are available online (at otn.oracle.com).

Is my partition table corrupt? Why does Boot Camp hate me?

Hi folks
I have an iMac (27-inch, Mid 2010) (iMac11,3, with Boot ROM IM112.0057.B01).
I replaced the internal SuperDrive with an SSD, which is now my primary boot device:
iMac:/ michthom$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS SSD                     248.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
iMac:/ michthom$ sudo gpt -r -vv show disk0
Password:
gpt show: disk0: mediasize=250059350016; sectorsize=512; blocks=488397168
gpt show: disk0: PMBR at sector 0
gpt show: disk0: Pri GPT at sector 1
gpt show: disk0: Sec GPT at sector 488397167
      start       size index contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6
         40     409600      1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640 484620800      2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
485030440    1269536      3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
486299976    2097159
488397135         32         Sec GPT table
488397167          1         Sec GPT header
So far so good.
I want to use the original internal HDD both to run Windows in Boot Camp mode, and to have a partition for my bulk data that doesn't need to be on the SSD.
I reformatted the HDD as a single HFS+ partition, GUID partition table.
I used BCA to create a Windows USB boot device from the Windows 8.1 media after following the hacking in this link.
When the iMac restarted after creating the 250Gb Windows partition on the internal HDD, I got the "no boot device" screen.
I restarted holding Option/Alt and booted from EFI Boot on the USB stick. Windows installer started, at least. Serial number accepted, on to picking a location.
The installation balked when I tried to select the BOOTCAMP partition, with the warning that the disk was formatted as MBR - eh? Why?
So, the current state of the internal HDD must be wrong somehow, but I don't see how to fix it (confidently) and would like someone to point me in the right direction (please!)
iMac:/ michthom$ diskutil list
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Internal                751.9 GB   disk1s2
   3:       Microsoft Basic Data BOOTCAMP                248.0 GB   disk1s3
iMac:/ michthom$ sudo gpt -r -vv show disk1
gpt show: disk1: mediasize=1000204886016; sectorsize=512; blocks=1953525168
gpt show: disk1: Suspicious MBR at sector 0
gpt show: disk1: Pri GPT at sector 1
gpt show: disk1: Sec GPT at sector 1953525167
       start        size index contents
           0           1         MBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6
          40      409600      1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640 1468478336      2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
1468887976      263256
1469151232   484372480      3 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
1953523712        1423
1953525135          32         Sec GPT table
1953525167           1         Sec GPT header
gdisk has this to say:
iMac:/ michthom$ sudo gdisk /dev/disk1
Password:
GPT fdisk (gdisk) version 0.8.10
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
MBR: hybrid
BSD: not present
APM: not present
GPT: present
Found valid GPT with hybrid MBR; using GPT.
Command (? for help): x
Expert command (? for help): o
Disk size is 1953525168 sectors (931.5 GiB)
MBR disk identifier: 0x4F5BB38B
MBR partitions:
Number Boot Start Sector   End Sector   Status      Code
   1                     1       409639   primary     0xEE
   2                409640   1468887975   primary     0xAF
   3            1469151232   1953523711   primary     0x0B
Expert command (? for help): p
Disk /dev/disk1: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3E1D7EF9-F86E-4552-8F40-BE9754C3C73F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 264685 sectors (129.2 MiB)
Number Start (sector)    End (sector) Size       Code Name
   1              40          409639   200.0 MiB   EF00 EFI System Partition
   2          409640      1468887975   700.2 GiB   AF00 Internal
   3      1469151232      1953523711   231.0 GiB   0700 BOOTCAMP
Any help / pointers gratefully accepted!
Mike

Thanks to Loner T and some more reading, I think I'm now sorted out.
I found that marking the first partition on the USB stick as Active made no difference - my only option was to boot from the "EFI boot" option at startup (when holding down the alt/option key).
So to get the Windows installer to behave, I used gdisk to write a new protective MBR before rebooting to the USB stick, as shown below.
With the protective MBR in place (rather than hybrid), the Windows installer was happy to reformat the chosen partition and the installation began.
I'll try to report back once all is installed and working, but once again I owe my sanity to the generosity and patience of strangers!
Mike
bash-3.2# gdisk /dev/disk0
GPT fdisk (gdisk) version 0.8.10
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
MBR: hybrid
BSD: not present
APM: not present
GPT: present
Found valid GPT with hybrid MBR; using GPT.
Command (? for help): x
Expert command (? for help): o
<snipped>
Number Boot Start Sector End Sector Status      Code
1                    1      409639 primary    0xEE
2                409640 1468887975 primary    0xAF
3            1469151232 1953523711 primary    0x0B
Expert command (? for help): p
<snipped>
Number Start (sector)    End (sector) Size      Code Name
1              40          409639 200.0 MiB EF00 EFI System Partition
2          409640      1468887975 700.2 GiB AF00 Internal
3      1469151232      1953523711 231.0 GiB 0700 BOOTCAMP
Expert command (? for help): v
No problems found. 264685 free sectors (129.2 MiB) available in 3
segments, the largest of which is 263256 (128.5 MiB) in size.
Expert command (? for help): x
<snipped>
n create a new protective MBR
<snipped>
Expert command (? for help): n
Expert command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/disk0.
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.
bash-3.2# gdisk /dev/disk0
GPT fdisk (gdisk) version 0.8.10
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): x
Expert command (? for help): o
Disk size is 1953525168 sectors (931.5 GiB)
MBR disk identifier: 0x00000000
MBR partitions:
Number Boot Start Sector End Sector Status      Code
1                    1 1953525167 primary    0xEE
Expert command (? for help): p
<snipped>
Number Start (sector)    End (sector) Size      Code Name
1              40          409639 200.0 MiB EF00 EFI System Partition
2          409640      1468887975 700.2 GiB AF00 Internal
3      1469151232      1953523711 231.0 GiB 0700 BOOTCAMP

Partition Table Looks Different Between OSX and Windows 7

Hey all,
I recently replaced the hard drive on my 2007 iMac, going from the 320GB drive to a 1 TB drive. It actually worked! The previous drive was failing in very odd ways, though booting into the Windows side (more on dual boot later) always seemed to work, and S.M.A.R.T. always reported that the physical drive seemed OK.
The previous drive (320 GB) had around 200GB devoted to OSX and 100GB partitioned off for a working Windows 7 installation (custom installed x64 Win7 Ultimate). I had the Windows system image backed up to my NAS, and had a Windows system bootable disc to restore that image.
After replacing the drive (and almost crying that I had actually done it right), I first restored OSX from a Time Machine backup, and let it take the full 1TB of space as Journalled HFS+. Then, I used Disk Utility to shrink OSX down to 500GB, and created a second partition (formatted to NTFS) with the remaining 500GB.
Now, restoring a Windows system image is an odd thing, as it tries to do a lot of partition work as opposed to simply restoring the Windows install to a partition. I tried Macrium Reflect first (made a backup in that, too), and it looked like it was going to let me restore to the second partition. It completed the restore...and the entire hard drive was hosed. Partitions had been moved, renamed, resized, and nothing was bootable. I had to use Recovery from an external USB thumb drive to go back to the single, full-drive install of OSX.
Then I tried again. Made the second NTFS partition and used the basic Windows System Restore disk to restore from the standard system image I had on the NAS. I was not expecting this to work. But it did. Windows started showing up in Startup Manager when "option" was pressed on bootup, and both OSX and Windows booted properly and ran fine. This is where I (finally) get to the supreme oddities:
OSX Disk Utility still reports two 500GB partitions, one for OSX and one for Windows.
In OSX the Windows partition shows as having NO DATA on it. Not sure what would happen if I tried to write a file to it when mounted, but there is no data on it when viewed from OSX (I was always able to see the Windows files when I mounted that partition on the previous drive).
The Windows partition does not show up as a valid bootable system in System Prefs --> Startup Disk (naturally, I suppose, since OSX doesn't think there is anything there).
From the WINDOWS side, Windows still sees the old partition table: 200GB for the "unknown" HFS partition, and then the rest of the space can be devoted to Windows (started as 100GB, but I was ablt to expand it to use the remaining ~750GB!). Windows thinks it can have 750GB of space even though I know its partition is only 500GB in size!
Windows cannot see the OSX HFS partition data using HFSExplorer. It CAN see the HFS partition on the attached backup drive (the drive I use for Time Machine).
GParted (a partition program on a Linux bootabld CD-ROM) shows the same partitions as OSX Disk Utility (2x500GB), and also thinks the Windows NTFS partition is empty (all space reports as "unused").
Did I mention both OSX and Windows work fine???
There are, of course, two other partitions on the drive: the first partition is the 200MB one I always see (EFI/GUID portion?), and then between the HFS and NTFS partitions is the 600MB recovery partition (which also shows at option-pressed boot time). OSX, GParted, and Windows see all four partitions, and in the same order. It is just that Windows sees the wrong sizes, and OSX cannot see any data in the Windows partition.
Surely this is all going to break spectacularly at some point, isn't it? What if I ever did write a file to the Windows side from OSX, or what if OSX starts taking more space than the 200GB Windows thinks is the max for that partition? What if I try to make Windows use more than 500GB because it thinks it has almost 800GB to use? What if I defrag the Windows drive?
I had no idea a partition table could look this goofy and yet still have everything be bootable and workable. Is there something I can do to get everything in sync? Basically, I am assuming I need to get Windows to do some low-level kung fu in Disk Manager in order to properly get everything lined up with the "right" partitions as reported by both GParted and OSX Disk Utility. But how do I do that?
By the way, any ideas that totally nuke the drive and start from scratch are completely fine (if it seems like they are doing something different enough that I'd give it a try). I have good backups of both OSX and Windows and have restored them about a half dozen times already as I dealt with the previous failing hard drive and with trying to get dual-boot working again. Not to mention, this iMac is now my secondary machine to the new Mac Mini I got a couple weeks back when I wasn't sure how much more life I was going to get from this 6+ year old iMac.
Thanks for listening to me ramble about this very odd issue, and a huge THANK YOU in advance to anyone who has ideas to help.
Thanks,
sutekh138

Update:
I am pretty sure the issue is a simple GPT/MBR discrepancy.
I installed rEFIt and used it's partitioning tool (gptsync built in) upon bootup. It was able to show the GPT table and the MBR table, but it thinks the second partition of the drive (the Mac OSX bootable partition) is "extended" in the MBR table and says "will not touch this disk."
However, it does look like an MBR sync should be straightforward, as there four partitions in the GPT table and four in the MBR (and MBR allows a max of four, AFAIK). I just need gptsync to relax some rules. I found a link to a supposedly newer version of gptsync compiled for OSX, so I will try that later.
First, I will try Partition Wizard, a free tool I found for the Windows side. It has a "Repair MBR" option that I would have tried last night if I weren't running a new Windows Image Backup in case all of this goes haywire. *smile* The PW tool also has an option to change the MBR over to GPT entirely. That might work, but then I am not sure Windows 7 will boot (from what I read, x64 Win7 running on EFI-enabled hardware should work, but who knows).
Anyway, I will try the following things, in order, until something works, when I get home tonight:
From Windows, run Partition Wizard and try "Repair MBR".
From OSX, download recent gptsync and try to run it.
From Windows, use Partition Wizard to do a full MBR --> GPT conversion.
Nuke the Windows partition in OSX Disk Utility, expand the HFS partition to take up the whole drive, and then add a Windows-bootable partition via Boot Camp-ish command line commands (diskutil). Because if nothing else works, I have to assume I just created the partitions wrong in the first place such that a Windows restore miraculously works, but the partition weirdness is just a timebomb waiting to happen.
Finally, if none of the above work, I'll just get things back to the way they now work and wait for the timebomb to (possibly never) go off. *smile*
I'll update this thread if I get something figured out, in case anyone else stumbles upon it...
Thanks,
sutekh138

Partitioned table takes more time to load

Hi,
Recently I have been test loading a partition table (Datawarehouse fact table). However, I notice almost 2X to 2.5X jump in timing compared to the non-partitioned table.
The partition is on the TIME Key on the basis of monthly range. Since this key is not entirely consistent (less than 1% cases) and can change sometimes, I have enabled row movement.
Is there anything that you can do to improve timing when everything else remains same?
Regards
Prem

Hi,
When you load data into a partitioned table oracle has to check every record
to decide in which partition store it.
When you load data in a heap table oracle hasn't to check it. All records
are saved in the same segment.
You can save time when you load in partitioned tables using partition
clause.
Regards
K.Rajkumar

"Invalid segment" when shrinking a partitioned table

Similar Messages

Maybe you are looking for