damorgan wrote:Two obvious things: As Tom Kyte points out (I think normally to say you need archivelog and recovery) non-prod is someone's prod; and sandbox systems for users to try complex operations without screwing up production. Yes, sometimes they do run into expectations issues due to noarchivelog or plan changes. That's life. You can have plan-change issues in production too.
How can a "test" system be someone else's production? A system either is a line-of-business system or it is not.
The bottom line on any discussion is a risk-reward determination. What risk is the customer willing to accept to compromise on an optimum configuration.Risk/Reward/Cost/Benefit is biased towards costs when accountants get involved.
If your customer is willing to give you three hours, three days, three week, three months to recover a system and restore it to operational capacity then perhaps NOARCHIVE, NOLOGGING, and No RMAN can be justified.In reality, it's "hey, you want your special db refreshed, let me know a day in advance." Then I push a few buttons and it all happens automatically overnight. Sometimes their special screwups can be refreshed on demand, depends what they did. They tend to think in Excel analogies after all, my job to make it happen or put it in terms they understand why not. People want their own copies of the database and don't really know how to ask for a subset that reflects their needs. "Duplicate Database" doesn't always reflect that either.
But to post advice in these forums based on these unusual system requirements may well lead people astray who's employers purchased the Oracle database because they want robust sytems, systems that are operational 7x24x365, systems that are their to meet business needs on demand.If they miss the part about making explicit SLA's (which I for one repeat ad naseum), not much we can do about it. It's certainly better than "Best Practice" advice, which isn't.
I don't even run my laptop in NOARCHIVE mode. I'm not even running the 12c Beta in NOARCHIVE mode. And I can not believe that you can truly justify doing so in your environment. I would be very interested in hearing the business arguments that appear to make this a reasonable choice juxtaposed against the cost of purchasing sufficient SSDs to eliminate the risk.Not buying SSDs is much cheaper than buying SSDs. Existing systems are often perfectly adequate (and yes, sometimes not - we just acquired a aix/cobol/vsam oriented division, should be interesting times). Acquiring storage is not linear, you have periodic budget cycles, different groups jockeying for space, various replication propagation methods beyond just Oracle, labor/administration, etc. etc. It's not just running down to Fry's and scooping up some T-sized drives.
Aren't (or won't they been soon) a significant portion of mission-critical databases Data Guarded? Certainly, that's mostly true in our world. In which case, you don't get a choice whether you do NOLOGGING or not.You can perfectly well run Data Guard with nologging tables present. You just have to deal with them when the standby is activated. By definition, you'd have used nologging for something that is recoverable without redo (i.e., can be re-loaded from external sources, for example). So there's nothing to stop you running with one or two reporting tables (say) in nologging mode and, at the point of activation of the standby, you drop or truncate them and re-create them. You can also use incremental rman backups to refresh the standby datafiles before the point of activation, if that's the sort of thing you want to try.
damorgan wrote:Just to offer a different perspective, I have occasionally been on sites where DBAs have had to spend literally days doing something massively labour-intensive (and, on rare occasions, system-threatening) because DBA's were viewed as a sunk cost - and not paid the appropriate overtime - while getting a new piece of equipment to do a job properly, safely, and quickly, would be new expenditure.
Businesses everywhere want to get business done at the lowest reasonable cost. If you can prove financial savings by spending money ... they will find it ... and they will spend it.
Consider this (from a US perspective of course) ... every DBA costs $100K/year. If I go to management and say "I want you to spend $150K on new hardware but you can eliminate one DBA position" the math after three years shows a savings of $150K with lower costs for recruiting, training, desk space, hardware, and software.
so it is increased but TOM's said it not generated redo , my database in archive mode
NAME VALUE ---------------------------------------------------------------- ---------- redo size 172472 SQL> l 1 select name,a.value 2 from v$sesstat a, v$sysstat b 3 where b.statistic#=a.statistic# 4* and b.name = 'redo size' and sid =95 SQL> alter table x nologging; Table altered. SQL> SQL> SQL> SQL> insert /*+ APPEND */ into x 2 select * from y; 107 rows created. NAME VALUE ---------------------------------------------------------------- ---------- redo size 174976
861100 wrote:Thumbnaill sketch:
hi Jonathan Lewis,
just to be clear , due to till now i'm confusing cuz the tom said if your in archive mod and your table in nologging and use append in hint
there is no redo will generated ??? but i tested it gerenrated redo ,
so there is no way to avoid generated redo but if you use nologging the redo that generated will be decreased ???
Note that there was no undo, and the redo has dropped accordingly
Baseline insert: redo size 1,459,804 undo change vector size 111,704 insert /*+ append */ redo size 1,326,620
We still get logged - until we use the append hint, which makes the insert a direct path load above the highwater mark - so we get (virtually) no redo or undo.
redo size 1,459,788 undo change vector size 111,704 /*+ append */ redo size 2,240 undo change vector size 492