Dear Friends,
I created a materialized view log on on EMP. And It created me two tables
which are (MLOG$_EMP and RUPD$_EMP).
Whats the purpose of this RUPD$_EMP pls?:o
Thanks
Printable View
Dear Friends,
I created a materialized view log on on EMP. And It created me two tables
which are (MLOG$_EMP and RUPD$_EMP).
Whats the purpose of this RUPD$_EMP pls?:o
Thanks
delete it, it means trouble. :)
what?:confused: are u kidding papa rey...why the trouble:rolleyes:
that means, it shouldn't be there. Only the MLOG$_.
why on earth do you say that????? what a stupid answer
rupd$ tables are there when the mv log tables have primary keys and it supports updateable mv's which can only be done on log tables with pk's
you really is a trigger happy Davey when it comes to negative remarks..:rolleyes:
Actually, It just popup into my mind 'coz I remember it once when I encounter an error like "ORA-995" or "ORA-955".
So if Jen didn't encounter any problem then be happy with your life.
That's why I mentioned "trouble", 'coz that's what I remember. I'm not into MVs lately, and yet I don't excuse myself.
You don't need to do that Davey coz I never give that kind of remarks when you're on the other side.
stop giving bad and wrong advice and you will stop getting called on it
:D cool dear
Quote:
Originally Posted by davey23uk
So the Mr. Perfect/Non-Rubbish Guy has really this role here.
Scan the below docs, just to give you an idea what I meant.
I just search this document for this purpose alone.
--------------------------------------------------------
DB PROPOGATE PROBLEM WITH SNAPSHOTS ORA-955
Doc ID: Note:251410.1 Type: PROBLEM
Last Revision Date: 04-AUG-2004 Status: PUBLISHED
The information in this article applies to:
affected Oracle Products:
oracle rdbms 8.1.7 - 9.2.
db propagate 9.2
Symptom(s)
~~~~~~~~~~
Db propagate of a schema containing materialized view logs (snapshot logs)
will result in "ORA-00955: name is already used by an existing object"
on a object with name RUPD$_.
This error will always happen, if db propagate contains the objects:
the snapshot log itself,the table the snapshot log is based on and the table
RUPD$_.
Cause
~~~~~~~
Creating one single snaphsot log on a existing table (containing a index)
will create three objects:
the snapshot log: MLOG$_
table: MLOG$_
tbale: RUPD$_
DB propagate suppresses the table MLOG$_but not the
table RUPD$_.
The db propagte script execution will first create the snapshot log and then
create the table RUPD$_, but the table is already -indirect- created
by the creation of the snapshot log and so a ORA-955 will be displayed.
Fix
~~~~
Remove the table RUPD$_from the db propagation.
------------------------------------------------------------
I would not drop anything created by Oracle, if I am not advised to do so by the Oracle Support or if I am not completely sure what this object is ment for, and that Oracle could function properly without it ( to be honest I do not remember such case, when Oracle creates something useless)
So, Jenny, it's up to you :-)
Regards
No offence but following that line of thinking I'm tempted to delete all my Oracle deployments, happens I got a lot of troubles using Oracle :cool:Quote:
Originally Posted by reydp
I can't delete it because it doesn't have any contents eversince it wasQuote:
Originally Posted by reydp
created:D do u mean drop the table dear?
I am curioous also because in all my readings about advance replication in
10g, I didnt come across topics about this rupd$...maybe its obsolete now?:confused:
hmmnn... I think papa rey just shared some exceptional problems :) negligibleQuote:
Originally Posted by PAVB
ones compared to lots of benefits oracle gives.
Troubles using oracle can be attributed to the user himself or his
knowhow about the product:D
So Jenn... when in a previous thread reydp told you...
...you actually got the "don't forget to press ENTER key" part of it as a literally legitimate advice, huh? LOLQuote:
Originally Posted by reydp
Now it all comes together to me
lol...i didnt understand what papa rey means by that dear:D my brain just picked-up the useful info here and disregard otherwise:p
I'm cool.Quote:
Originally Posted by PAVB
You're right. I stand corrected for that. No problem.
Maybe it's because I have used MatViews eversince it was first introduced but not lately. And that my line of thinking when this thread was open tends to recall only the obnoxious scenario rather than usual one.
But if you are to challenge if I really know the subject matter, you might try to search my archive posts here that tackles MatViews problem and issues. Long before you become a member of this forum.
Or, maybe have an exchange of ideas with the topic for examples:
"MAT VIEWS - best for DW/DM but never in OLTP", how's that.
Nice try anyway, for pursuading Jen to hate me..... she's still nice to me..sorry :)
Jenn is allways nice :-)
off topic
Jenn I see you use lots of replications. Have you tought about using streams?
Cheers
Yes dear...I read a little about it...it seems they served the same purpose
though:)...but as of now I have to choose the one I had studied earlier first
because my boss is pressuring me to implement this replication thing. He even
ask me to show the demo on how it is going to work. He got a lot
of questions like how much time did it take to replicate an image in a
single row :rolleyes: We have to interconnect/replicate 30 branches, good
thing the WAN is not stable yet, so I gives me a little buffer time:)
So as of now I don't have the luxury of time to learn more about "streams"
Do you think it is better that replication dear? Can u tell me whats the
difference between the two?
Thanksss
I'm not Rey, I know you are good and, you have nothing to prove to me.Quote:
Originally Posted by reydp
Wasn't trying to do that. It's clear you have Jen eating from your hand. :)Quote:
Originally Posted by reydp
About the streams, it is relatively new technology ( since 8.1.7) but Oracle says it will replace replication.
The idea is,
1) You have a queue, where messages can be queued
2) You have a process, called capture process, which captures the changes in the source database ( up to you to set it up what to capture) and generates messages. Then queues these messages into a queue ( implemented as a DB table in fact). The message contains the captured change
3) You have a propagator process, which can propagate messages between different queues ( including remote queues, over db link)
4) You have apply process, which dequeues changes and applies that locally
Why it is better - much more flexible.
Can configure rules what to apply and what not to,
Can transform the message, so that a change, captured at one local table to be applied to another destination table - different owner, different name, different colums even.
Can consuruct your own messages, using an API and queue them, so that later on they gets applied by the apply process
It is nice to know streams, since they are used not only for replication but virtually anywhere - as an integration mechanism ( exrernal systems queuing XML messages with data and hence entering your system, document management, the enrerprise manager even uses streams to queue the server generated alerts)
That's what I know :-)
Not much but exiting enough, isn't it?
hmmnn....nice explanation dear....sounds similar to log miner...where u can
see all the process being done on the database and you can audit which
table was being modified by what user and report some fraudulent tampering
of data:cool: Ok I try read it and give it a test....hhmmn i hope i wont be
able to sleep:D
Thanks again xxxxxxxxxs
hmmm... I believe that includes you, and boris, and some of us here. :)Quote:
Originally Posted by PAVB
Anyway, for the Oracle Streams which boris mentioned, from what I know
the improvement was more in AQ(Advance Queueing), I remember problems using AQs in 9i/10g
where in queued process sometimes can't continue when let's say the db server gets down abnormally
and restarted. Then most of the recomendation was to use Streams specially
when the version is already in 10g. And from what I've read from Tamil, Streams are not yet stable
if you are going to use it specifically for Replication.
Hi all....yes, I got what u meant now:) .
While I am testing our replication set-up I noticed that when the network
connection is broken(long enough) or the server is down. I got "BROKEN" status in my refresh group, and It does not automatically go back to "NORMAL"
status even when the connection is already GOOD. So, you have to manually
refresh it using OEM. and if u have a critical data that need to be replicated
immediately then u have to check the status often.
Did you encounter the same problem?
I thinking of a OS scheduled script the will check every minute if the refresh group is "BROKEN" then it will run the progem like this :
BEGIN
DBMS_REFRESH.MAKE(
name => '"MVADMIN"."GROUP1"',
list => '',
next_date => SYSDATE,
interval => '/*10:Secs*/ sysdate + 10/(60*60*24)',
implicit_destroy => TRUE,
lax => FALSE,
job => 0,
rollback_seg => NULL,
push_deferred_rpc => TRUE,
refresh_after_errors => TRUE,
purge_option => NULL,
parallelism => NULL,
heap_size => NULL);
END;
/
Do you have any idea how to make the script?:)
Thanks
Jenn,
I gave not dealed witrh replication for a long time but I remember that the behaviour you see is intended behaviour. Replication operates like that and there is nothing strange here
The job is not necessarily be OS level job. You can use dbms_job as well.
Also, It wold be good if U put new questions in new threads instead of adding to existing one. That's much clearer
Cheers
Boris
Ah ok :) thanks honey....
So I was wrong when I explain to my boss that replication is automated....
even when network is cut-off and restored or server is down and up:o .
Well, it's like that
Replication tries to propagate changes. If that fails, rep tries it again say after 1 sec. If it fails again, it tries after 2 sec.If it fails again, it tries after 4 sec and so on, until a treshold is reached (don't remember but after several tries)
Then the rep gives up, marks the job broken and never tries again. Here u should manually restart the process when everything is fine again
Cheers