JuSt SoMe FAQ

whats is problem if segment initial extent is high??

I think propagating wasted space is a legitimate concern. Imagine if someone were on a version with deferred segment creation, they clone empty table, no problem, then the first time they add a row the whole initial extent needs to be formatted… do I have that right, I don’t have the setup to try it myself.

I have seen such propagation issues with original exp compress=y going back to the last century. I just tried it in 10.2.0.4 with lmt, exp a 36 million row table rows=n compress=y, imp into a user with a much smaller tablespace that didn’t have the table already, ORA-01659: unable to allocate MINEXTENTS beyond 29 in tablespace … it was trying to do INITIAL 4294967294, which I think is a max based on platform and blocksize.

That’s why I have a habit of thinking about how much data is coming in and pre-creating the tables. LMT may be more efficient about tracking blocks and figuring out where to grab new extents, but it still helps to get all that stuff done before a major in-migration of data, especially if you have large tables that have to exist but aren’t being propagated. I consider it all required basic dba work, not an obsolete worry.

we are planing for storage migration eg. Sun ZFS Storage 7720 to p 6000.Is it possible or not??
The capacity is already 720 TB in 7720.Number of hosts is 112 among them 3 is most newest hosts they are in VMware ESX 3 cluster.

sure that possible, but you have to migrate the data by using host-based mirror, backup/ restore or, in case of VMware VI3, by using storage vmotion.

we can use those techniques for XP migrations too. Those techniques are independent from the used storage hard- or software.

Take a closer look into the VMware documentation regarding storage vmotion/ moving VMs to different datastores. If you’re using VI3 you have to trigger a svmotion by using the remote CLI. Just connect the new volumes to the ESX servers, create new datastores and move the VMs online due svomtion to the new storages.

If your hosts can do software-mirroring you can use mirroring for migration data. Just connect new volumes to the host an mirror the data to the new volumes.