I wouldnt use a materialized view log for anything by refreshing a materialized view.
Because you're taking a huge gamble if you do so...
SQL> create table t ( x int primary key, d date );
Table created.
SQL>
SQL> create materialized view log on t including new values;
Materialized view log created.
SQL>
SQL> insert into t values (1,sysdate);
1 row created.
SQL> update t set d = d + 1;
1 row updated.
SQL> delete from t;
1 row deleted.
SQL> desc MLOG$_T
Name Null? Type
----------------------------------------------------- -------- ------------
X NUMBER
SNAPTIME$$ DATE
DMLTYPE$$ VARCHAR2(1)
OLD_NEW$$ VARCHAR2(1)
CHANGE_VECTOR$$ RAW(255)
XID$$ NUMBER
SQL> select * from MLOG$_T;
X SNAPTIME$ D O CHANGE_VECTOR$$ XID$$
---------- --------- - - ------------------------------ ----------
1 01-JAN-00 I N FE 3.0963E+15
1 01-JAN-00 U U 04 3.0963E+15
1 01-JAN-00 U N 04 3.0963E+15
1 01-JAN-00 D O 00 3.0963E+15
4 rows selected.
So what happens when the next patchset rolls out, and we (Oracle) decide that we wont have a DMLTYPE column anymore, we're going to store the dml action inside the raw content of CHANGE_VECTOR.
We can do *whatever we want* with the MLOG$ table, because its an *internal* table.
If you want to replicate changes (to SQL Server), then I'd recommend options such as triggers to capture the data, then your process as you've already described, or look at a tool like Goldengate.
Hope this helps.