Ecimen wrote:No, the only thing that you can disable is whether that table can generate redo or not(that too won't be a completely correct statement to make but anyways) . I am not sure that there is any such option or command that would let you skip generating the Undo, either for a schema or for a table.
The size requirement of the undo tablespace is related to the number and size of transactions that occur on the database.But I dont need to query any of these transaction for a schema or table by using flashback so is there a way of disabling writing any transactions on a table or schema to undo tablespace ?
Ecimen wrote:What I meant with that added note that it's not possible to say that you would not be generating any redo at all , even if with the option like NOLOGGING. Oracle would only minimize the redo generation for your operation but it won't be ever gone to zero! That's why I said that you may say that we can stop the redo generaion but it won't mean completely .
what do u mean by saying "(that too won't be a completely correct statement to make but anyways)"...
thanks alot for helping
Rob_J wrote:hello Rob;
If you're generating a lot of UNDO it must mean that you are logging a lot. Perhaps you could reduce the level of logging or make it so that you can use a sample of logging or so that the logging can be turned on and off if it's for issue resolution.
Mihael wrote:Hello Mihael ;is there a way of disabling writing any transactions on a table or schema to undo tablespace ?You can create External tables and write to them using file operations. No undo, no redo.
so altering log tables with nologging clause will help reducing size of undo tablespace?Is there any relationship between nologging and Undo ?
Rob_J wrote:Hello Rob;
No, that's not what I meant. What I meant was that if you say your logging tables are creating a lot of UNDO it must mean that you are writing/updating/deleting a lot of information from them. I was just throwing out the thought that if this is the cause of the issue, can you reduce the amount of data you write to these tables? In other words, do you need all this logging data? It's a question for the business and/or designers of your application to answer.