Yeah, you can split/merge partitions in an MV. And any outstanding changes will remain in the mv log:
create table t ( x primary key, y not null ) as
select rownum x, rownum y from dual connect by level <= 1000;
create materialized view log on t;
create materialized view mv
partition by range (x) (
partition p0 values less than (501),
partition p1 values less than (1001),
partition pmax values less than (maxvalue)
)
refresh fast on demand as
select * from t;
insert into t values (0, 0);
commit;
select x from mlog$_t;
X
----------
0
select count(*) from mv partition (p1) ;
COUNT(*)
----------
500
alter table mv merge partitions p0, p1
into partition p1 update global indexes;
select count(*) from mv partition (p1) ;
COUNT(*)
----------
1000
alter table mv split partition p1 at (100)
into (partition p0, partition p1) update global indexes;
select count(*) from mv partition (p1) ;
COUNT(*)
----------
901
select x from mlog$_t;
X
----------
0
exec dbms_mview.refresh('mv', 'F');
select * from mv where x = 0;
X Y
---------- ----------
0 0
"are there some locks imposed on the mview log while these operations are handled."
What exactly is your concern here?