You're right, it is obvious, but I hadn't yet done it. The thought had occurred to me to do this at both nodes, but I think lack of sleep has dulled my senses a bit and I forgot to do it. All the work involved in repeating myself in the TAR maybe, I dunno.
I've dropped and recreated the offending MV's and associated logs: they seem to be working now. All very strange. I'm going to trace both ends if it acts up again. Thanks, Jared On Tuesday 25 February 2003 02:29, Connor McDonald wrote: > Probably a little obvious, but what do you get when > you slap a trace on the refresh job (on both source > and target db's) - do you see any attempt to read rows > from the mview log at all? any updates being attempted > on the target? > > hth > connor > > --- Jared Still <[EMAIL PROTECTED]> wrote: > > > > Dear list, > > > > Have any of you every experienced MV's not > > refreshing > > for no particular reason? > > > > We have been using some simple MV's for several > > months > > with no problem. Now after upgrading our app and > > database, > > there seem to be problems. > > > > Servers: > > > > Master: Win2k SP2 Oracle 8.1.7.4.1 > > > > Slave: NT 4 SP6 Oracle 8.1.7.4.1 > > > > These databases were previously 8.1.6. The master > > database > > now has a UTF8 character set, and all tables have > > NVARCHAR2 > > columns. > > > > These are being converted in the MV using: > > translate("COLUMN_NAME" using char_cs) > > COLUMN_NAME > > when creating the MV. > > > > There are no errors, no trace files. Data is > > updated on the master > > node and never appears in the slave. > > > > The data continues to persist in the MLOG$ tables. > > I've verified there > > is only a single MV against each MV LOG, so the data > > in MLOG$ should > > be truncated after a refresh, but the fact that it > > isn't makes it fairly > > obvious that the refresh is not working properly. > > > > I have a serverity 1 TAR open now with Oracle, but > > so far all that's > > been accomplished with the TAR is me repeating > > everything I > > included initially. > > > > Any advice appreciated, as it's rather important to > > get this working again. > > > > Jared > > > > -- > > Please see the official ORACLE-L FAQ: > > http://www.orafaq.net > > -- > > Author: Jared Still > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services -- 858-538-5051 > > http://www.fatcity.com > > San Diego, California -- Mailing list and web > > hosting services > > --------------------------------------------------------------------- > > > To REMOVE yourself from this mailing list, send an > > E-Mail message > > to: [EMAIL PROTECTED] (note EXACT spelling of > > 'ListGuru') and in > > the message BODY, include a line containing: UNSUB > > ORACLE-L > > (or the name of mailing list you want to be removed > > from). You may > > also send the HELP command for other information > > (like subscribing). > > ===== > Connor McDonald > web: http://www.oracledba.co.uk > web: http://www.oaktable.net > email: [EMAIL PROTECTED] > > "GIVE a man a fish and he will eat for a day. But TEACH him how to fish, > and...he will sit in a boat and drink beer all day" > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).