We have a few NFS mountpoints used for things that would not be an entire
catastrophe if they were inaccessible for a brief time. The only time I’ve had
a problem is when we moved physical database servers, NFS mountpoints were a
new thing, and the sys admin forgot to put the mount into the startup. Other
than that, it’s been very reliable. We use shared mount points between servers
for our Data Domain device for nightly exports and backups. That device is
replicated off site.
I specifically say ‘brief time’ because everything we do is important, it’s the
downtime tolerance that’s important. For example, ORACLE_HOME could never,
ever be inaccessible, that outage tolerance is zero downtime.
From: Michael Cunningham <napacunningham@xxxxxxxxx>
Date: Thu, 2 Jun 2016 22:02:16 -0700
Subject: Is nfs reliable?
I had someone tell me today that nfs should not be relied on and it should not
be used for a shared mount that needed to be reliably available.
Has anyone ever hear this before?
Michael Cunningham
*********************************************************
Sherrie Kubis
Database Team Lead
Information Technology Bureau
Southwest Florida Water Management District
2379 Broad Street
Brooksville, FL 34604-6899
352.796.7211 x4033
sherrie.kubis@xxxxxxxxxxxxxxxxxx
Please take a moment to answer a few questions and let us how we’re doing.
IMPORTANT NOTICE
E-mails made or received in conjunction with the official business of the
District are public records. All e-mails sent to and from this address are
automatically archived. For more information regarding the State of Florida
public records laws, please visit www.myflorida.com.
-----Original Message-----
From: FreeLists Mailing List Manager [mailto:ecartis@xxxxxxxxxxxxx]
Sent: Friday, June 03, 2016 1:05 AM
To: oracle-l digest users <oracle-l@xxxxxxxxxxxxx>
Subject: oracle-l Digest V13 #144
oracle-l Digest Thu, 02 Jun 2016 Volume: 13 Issue: 144
In This Issue:
Re: UNDO free space considered expired/unexpired undo which
Re: Oracle RAC and coomvault(10) integration
RE: Oracle 12C on Z/OS
Is nfs reliable?
----------------------------------------------------------------------
From: sumit Tyagi <dba.tyagisumit@xxxxxxxxx<mailto:dba.tyagisumit@xxxxxxxxx>>
Date: Thu, 2 Jun 2016 11:55:43 +0530
Subject: Re: UNDO free space considered expired/unexpired undo which views to u
http://ora10gadmin.blogspot.in/2012/05/ora-1555-famous-snapshot-too-old-error.html
<http://ora10gadmin.blogspot.in/2012/05/ora-1555-famous-snapshot-too-old-error.html>
On Thu, May 26, 2016 at 12:11 AM, Dba DBA
<oracledbaquestions@xxxxxxxxx<mailto:oracledbaquestions@xxxxxxxxx>>
wrote:
Oracle 12c, this is the one I am currently looking at, but I don't
think this issue is any different from an 11g DB.
Autoextend off: I know oracle calculates free space on undo
differently whether this is on or off.
Referencing Link on Expired vs. Unexpired Undo:
http://www.toadworld.com/platforms/oracle/b/weblog/archive/2015/06/15/
how-does-oracle-reuse-the-expired-and-unexpired-undo-extents
Problem: Want to write a generic query that tells me how much free
space I have in each tablespace. It will also include UNDO and my
assumption is that all EXPIRED UNDO can be reused so its effectively free.
First I post a query I wrote that treats expired undo as 'free space'
for monitoring purposes. Is this the correct way to handle it? Then
below that I post DDL from DBA_TABLESPACE_USAGE_METRICS and I have a
question about it.
Query to monitor free space: Treats expired undo like 'free space'
with freespace as
(SELECT d.tablespace_name, sum(nvl(d.bytes,0)/1024/1024) as
Free_Space
FROM sys.dba_free_space d
GROUP BY d.tablespace_name ), total as
(SELECT tablespace_name,
sum(decode(autoextensible,'NO',bytes,maxbytes))/1024/1024
TOTAL_SPACE,
sum(decode(autoextensible,'NO',0,maxbytes -
bytes))/1024/1024 EXTEND_SPACE
FROM sys.DBA_DATA_FILES
GROUP BY tablespace_name
),
expired_undo as (select tablespace_Name,
sum(nvl(bytes,0)/1024/1024) as expired_Space
from dba_undo_extents
where status = 'EXPIRED'
group by tablespace_Name)
select b.tablespace_name ,
(case when a.tablespace_name != expired_undo.tablespace_name
then round((nvl(Free_space,0) + EXTEND_SPACE) /total_space*100,0)
else round((nvl(Free_space,0) +
round(nvl(expired_undo.expired_space,0)) + EXTEND_SPACE)
/total_space*100,0) end )
from freespace a, total b,expired_undo where a.tablespace_name =
b.Tablespace_name (+)
Section 2:
DBA_TABLESPACE_USAGE_METRICS: See DDL below for the undo tablespace
section. When I query this view, the % used output does not seem to
take into account 'expired undo'. I get a much higher percent used
than I do with the query I wrote above.
Check the DDL:
select dbms_metadata.get_ddl('VIEW','DBA_TABLESPACE_USAGE_METRICS')
from dual;
Section on undo tablespce below
Link to Doc on v$filespace_usage. Note that this section uses the FLAG=6.
The flags are not documented in the standard oracle docs. What does
this mean?
http://docs.huihoo.com/oracle/database/12cr1/server.121/e17615/refrn30
333.htm
SELECT t.name, sum(f.allocated_space), sum(f.file_maxsize),
(sum(f.allocated_space)/sum(f.file_maxsize))*100
FROM sys.ts$ t, gv$filespace_usage f, gv$parameter param
WHERE
t.online$ != 3 and
t.bitmapped <> 0 and
f.inst_id = param.inst_id and
param.name = 'undo_tablespace' and
t.name = param.value and
f.flag = 6 and
t.ts# = f.tablespace_id
GROUP BY t.name, f.tablespace_id, t.ts#
Does anyone have any experience with oracle and commvault.
Our sys admins have purchase commvault for our backups.
Iam having a hard time to configure get backups runing in our RAC database.
Database (11gR2) is runing on OEL 6.5
I keep geting this error in the commvault Rman Log:
using target database control file instead of recovery catalog
allocated channel: ch1 channel ch1: SIDC instanceÛ01 device
type=SBT_TAPE channel ch1: CommVault Systems for Oracle: Version
10.0.0(BUILD116) sent command to channel: ch1 Starting backup at May
31 2016 21:05:42 channel ch1: starting incremental level 0 datafile
backup set channel ch1: specifying datafile(s) in backup set input
datafile file number> input datafile file number>
name=+DATA/db/datafile/cam01.1159.852305661
input datafile file number>
name=+DATA/db/datafile/cam02.1283.870283233
input datafile file number>
name=+DATA/db/datafile/undotbs1.1264.789648943
input datafile file number>
name=+DATA/db/datafile/undotbs2.1089.789648951
input datafile file number>
name=+DATA/db/datafile/system.1182.789648935
input datafile file number>
name=+DATA/db/datafile/indexes.1268.790949691
input datafile file number>
name=+DATA/db/datafile/sysaux.1189.789648939
input datafile file number>
name=+DATA/db/datafile/sysaux.2177.837015981
channel ch1: starting piece 1 at May 31 2016 21:05:43 released
channel: ch1
RMAN-00571:
===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
===============
RMAN-00571:
===========================================================
RMAN-03009: failure of backup command on ch1 channel at 05/31/2016
21:05:50
ORA-19506: failed to create sequential file,
name="3057_DB_njr70dt7_1_1", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
sbtbackup: Job[3057] thread[64846]: Unable to contact the client..
Would apreciate if anyone can point me on the right direction,
Regards,
Arestas
--
//www.freelists.org/webpage/oracle-l
______________________________________________________________________
Wm Morrison Supermarkets Plc is registered in England with number 358949.
The registered office of the company is situated at Gain Lane,
Bradford, West Yorkshire BD3 7DL. This email and any attachments are
intended for the
addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by
replying to the email that you have received in error and then destroy
the email.
If you are not the intended recipient, you must not use, disclose,
copy or rely on the email or its attachments in any way.
This email does not constitute a contract in writing for the purposes
of the Law of Property (Miscellaneous Provisions) Act 1989.
Our Standard Terms and Conditions of Purchase, as may be amended from
time to time, apply to any contract that we enter into. The current
version of our Standard Terms and Conditions of Purchase is available at:
http://www.morrisons.co.uk/gscop
Although we have taken steps to ensure the email and its attachments
are virus-free, we cannot guarantee this or accept any responsibility,
and it is the responsibility of recipients to carry out their own
virus checks.
______________________________________________________________________
