RE: oracle-l Digest V13 #144
Date: Fri, 3 Jun 2016 14:47:50 +0000
Message-ID: <BY1PR09MB0535064B2A27BE7393F1F13F89590_at_BY1PR09MB0535.namprd09.prod.outlook.com>
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_at_gmail.com>
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_at_swfwmd.state.fl.us
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_at_freelists.org]
Sent: Friday, June 03, 2016 1:05 AM
To: oracle-l digest users <oracle-l_at_freelists.org>
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_at_gmail.com<mailto:dba.tyagisumit_at_gmail.com>>
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_at_gmail.com<mailto:oracledbaquestions_at_gmail.com>> 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#
>
>
--
*--* *BR* *Sumit Tyagi* *+91-7829543355* ------------------------------
Date: Thu, 2 Jun 2016 10:21:13 +0100
Subject: Re: Oracle RAC and coomvault(10) integration
From: John Hallas <john.hallas_at_morrisonsplc.co.uk<mailto:john.hallas_at_morrisonsplc.co.uk>>
These are some of our notes that may help. It looks as if you need to specify the location of the CV library in your allocate channel command When allocating a channel, in RMAN, the following ENV parameters may be
helpful:
ENV ParameterDescription
CvClientName Server to restore to. Destination Server.
CVOraRacDBClientName Server that the backup was created on. Source Server.
CVInstanceName Instance001. (No other values allowed under current
configuration.)
CVOraRacDBName Source *and* destination Database name. You can only
*restore* a database, not *clone* it to a new name.
See caveats below
<http://dbawiki.unix.morrisons.net/simpana_commvault#commvault_caveats>…
The following options are required when running a backup or restore manually through RMAN:
*RAC Database:*
allocate channel ch1 type 'sbt_tape'
PARMS="SBT_LIBRARY=/opt/simpana/Base/libobk.so,BLKSIZE&2144,ENV=(CvClientName=[target_host],CVOraRacDBClientName=[source_host],CvInstanceName=Instance001,CVOraRacDBName=[Database_Name])"
On 31 May 2016 at 21:14, carlos castro <ccastro7145_at_gmail.com<mailto:ccastro7145_at_gmail.com>> wrote:
> 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
> --
> http://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.
> ______________________________________________________________________
>
--
*Technology Manager - Databases*
Wm Morrison Supermarkets PLC
Tel 0845 611 4589 (Int. 7949 4589)
Mob: 07876 790540
E-mail: john.hallas_at_morrisonsplc.co.uk<mailto:john.hallas_at_morrisonsplc.co.uk>
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.
From: Robert Freeman <rfreeman_at_businessolver.com<mailto:rfreeman_at_businessolver.com>>
Subject: RE: Oracle 12C on Z/OS
Date: Thu, 2 Jun 2016 15:34:42 +0000
:÷«¶ŸŠ÷²yªì#¬ÂŠäŠx¢³«iÉ^¢{axû›–',yËh®È{ò)ëmÊkœ†‰åÉך–Ü"¶1iÖkù¨²ÙrjÛaxWz¶¥jwlµ«^•ëÞ–ÏÈÿÿݱ¬…«Z®‹§wÝÿ¡ûazئz)톋‑q«‑²Ø^0jÉš¨"ž kzÛršç!z÷«ÊØbžÈ¶§‘©h¶‡í†+0jËajÑ1iÖk¬ž‹hž\šì)•«_¢¹ÿnëky©eËÿÿjw°r‰Üz›ÿÿü"¶m观šÞ¶Ü¦¹ÈZÿÿÝjÖœz{^¯ÿÿŠv›£Ò£ûaŠÉ^~Ö¥¢Ú!8+¢êl¶¼¢ž h~(.ê.¶0¶‰š¨‑¶§‚ÏÓ…ç^}«¥¶Çž™çm¢)â¶&¥—&Þ•ëm…àÁÚ"µ©ÝÁì"–W"É^jº.ÙZµêí¡ø º·¨ºØŸ¶æ¥—(¬¶›zËpk/Èj[(±¬&j|¬ŠÛš¶*'³^âÁ«'ÿÿíz÷§k«zØZ´LZu«ZÁ« ¢h§‚Ø^Š¼Ëÿÿ²‹az·°jË(™ë ©›–)à¢{ay§fŠx¬¶¶Š‰ì‰×ÿN°k*®j»^®\©j×!Šx"²Çº˜ŠÉ®rš²'«¶†¥–Œ-…àÁÚ!j÷švh§iÇ‑²Ë(¶²q©ãºËij×!¶°†‰^¶§ƒôájßÿþɲµ©‑ÿÿÑ¡·«´Zè›ú+iÉ^þ_Û¢éÜ{÷ëyéb²Ûÿ¢¸ÿ™¨¥¶è§%{ùÿn‹§qïß祊ËlþŠàüéÁz¥|çÅç¤ñè¢ ’z{ÿI«nÖ²üƲÛÏöÓ^·ÿn‰Ùü䇋óhµ©ÚžÌ‑®Ú2¢êê¹ë-Š‰ÿnëHþl(׫Šx"ž0™©ò¦VœzˬŠxŧZµ¯âµªÞ¶¬ÊË^™§fŠ{0††«z·¬¦‰ì‰¹^~Šæj)íj)âž ax䨞Ø^{jÖÿ¢»azËh¨‑iÙ¢žËh™¨§µ¨§¶€HË-¢¶ {ÿÈžlžÆ—«‰éÜ{øj·…àÁû0††«z·¬¦‰ì‰¹^~Šæjv Šx-…秶*ÞnŒÿu«Zm«‑³û-¢¶ y©Ý¢Ïÿjw_¢ºZµÈbžÿôáz·¢²0z÷«ý«&jYi¢Ë"n)b·+ajÙ²{^®'§q謞‹kzšÞ±éíjد{ÿÿJ‚0¢é]–‹Þ¶ˆ^j·ë¢kaz‹az»(žØb²X¬·Z¶Ø^Š·±¥êâzw‑±ªÞü¨§v· j·lüZÞz_at_ÿ‑Š xéï¯ý´×¯ôçý»jÝzÿn~ÓM4þºþŠÚrW°‹6«w÷(›ùšŠ[hþºþŠÚrW°‹6«w÷(›ü+¢×ÿYée›!/ŠZej{-j»^w† ¶)ඬrë-¢g«¡÷è~»§ž)à:¶œ•ê'Â)Ý£ ,z»Þ®ÏÈžØb²™ZŸò ¢ÖîÊ)èœLZ u«Z¶‡h¶œ¢{(–'Z¶*'ý8^챬+Šy%z)æÊ™ZŸûaŠË!¢˜Z²z‑Æ—«‰éÜz)ËŠ{±¢´¨•ªâ²Ê-…å¢Ú0±§fŠ{,µªíy×(š™ZŠx§ƒöåi¹ZnVÿ"{ayéÝŠÖ©¥æ«²Ø^uên· ˆ:¬²-vŒ'›*ejÈÿÿæž‹hëhÂ)ÞþÊ"~Ø^ŠË.z+ÿÿü!j×hÁèZ½ç±¥êâzw‑Â+aÿÿⱩšŽŠÝ®+Þ®Ø^žØb²Èh¦+–Ê"žš,±ë,Š‰è}¦uÑ«h¦z-r.¦š+¶ËZ}ö§vØ^jË(r&yا~¶¬¶»œ¶êÞüÚ0"¯zÚ ¢Ú&ÈK╶œ’êi•©ÿš(+j×…è«u«Zm«‑²Ú5Ø#à ÿÿ²‰í…æuÓó2v*ÞrÚ+ÿnryªì™¨§~¶¦z̬µé©®ˆ+již¯ÿÚÛp êÚrWƒÿþÏðŠØh½ê÷ç'š®ÉšŠwëjgžÆ—«‰éÜy朇ö¥–Z/zØb²'^³ó2v*ÞrÚ+ŠÈ(Šx-¢ ²‰ž³+-zk-jÛ(žØ^g]-¢Çž‰ûaz·¢±éèºm…êÞ¶ˆh²Ú.¬êÚrWƒjÖ›jǬüz0z÷«mçèâ ®+Þ¶¬¶¶¢žÚ(}ªÝ£ í…ëkiÉçi¸¡ö¾'‑ÿ_áë§%{]‚jwC g({¬¶Éâqér¢v9/öü&§Ê‹©¢)í™ëhj|¡Šez÷¥¥ª^®Ê'×`¨ŸÎKýÿ·…êÞj|yÈg‰Æ¥ŠË.zÊ.¶Ø^ëajÜ‑².•×(žÈz¶ÞʉÝjö¢•¦åz̬µé«zÊ.Ǭÿôh
From: Michael Cunningham <napacunningham_at_gmail.com<mailto:napacunningham_at_gmail.com>>
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
End of oracle-l Digest V13 #144
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Jun 03 2016 - 16:47:50 CEST