Just had a look and you did indeed Norm. However no mention of checksyntax. Have a good 2017
↧
Comment on RMAN checksyntax function by John Hallas
↧
Comment on RMAN checksyntax function by zhwsh
if you using 10g:
$ cat r.rman
run
{
allocate channel c1 device type DISK;
allocate channel c2 device type DISK;
release channel c1;
release channel c2;
}
$ rlrman checksyntax
Recovery Manager: Release 10.2.0.4.0 – Production on Fri Dec 30 10:04:06 2016
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: STATISTI (DBID=3581654166)
RMAN> @ r.rman
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found “identifier”: expecting one of: “allocate, alter, backup, beginline, blockrecover, catalog, change, connect, copy, convert, create, crosscheck, configure, duplicate, debug, delete, drop, exit, endinline, flashback, host, {, library, list, mount, open, print, quit, recover, register, release, replace, report, renormalize, reset, restore, resync, rman, run, rpctest, set, setlimit, sql, switch, spool, startup, shutdown, send, show, test, transport, upgrade, unregister, validate”
RMAN-01008: the bad identifier was: r
RMAN-01007: at line 1 column 2 file: standard input
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found “dot”: expecting one of: “allocate, alter, backup, beginline, blockrecover, catalog, change, connect, copy, convert, create, crosscheck, configure, duplicate, debug, delete, drop, exit, endinline, flashback, host, {, library, list, mount, open, print, quit, recover, register, release, replace, report, renormalize, reset, restore, resync, rman, run, rpctest, set, setlimit, sql, switch, spool, startup, shutdown, send, show, test, transport, upgrade, unregister, validate”
RMAN-01007: at line 1 column 3 file: standard input
RMAN> @r.rman
RMAN> run
2> {
3> allocate channel c1 device type DISK;
4> allocate channel c2 device type DISK;
5> release channel c1;
6> release channel c2;
7> }
The cmdfile has no syntax errors
RMAN>
RMAN> **end-of-file**
–between @ and r.rman have not bloank. I take me about 2 hours.^_^
↧
↧
Comment on RMAN checksyntax function by John Hallas
Interesting but not an issue with Oracle per se.
↧
Comment on Performance problems with OEM AWR warehouse by Ian Greenwood
Hi John,
Couple of things worth investigating:
1. Sequential reads are slow – > 8ms average per read. This is much slower than expected – I remember investigating an IO issue on one of your DBs a couple of years ago when, I believe, the average sequential read was around 7ms. I think that this turned out to be a SAN configuration issue.
2. If the sequential reads cannot be speeded up, then try gathering system stats under a representative load to allow the optimiser to use more realistic io stats. This may help it to tip towards a FTS
3. Check if there are sufficient histograms on the BO# column on the tabpart$ and indpart$ tables. Because this code is likely to be looking only at the WRH$ tables, there is a high likelihood that the object ids for these tables will be contiguous as they are all generated from the same script; and as the WRH$ partitioned tables are the only ‘real’ data in the AWR warehouse then the partition details are going to be heavily skewed towards those tables. Could be using index if not aware that data is skewed.
4. Could look at altering _small_table_threshold parameter to increase likelihood of direct path reads, this is a last resort. But generally direct reads will be cheaper that scattered reads as not using buffer cache. Parameter adjusts threshold at which table is regarded as too big to fit into cache.
Regards and Happy New Year
Ian
↧
Comment on What is the future for an Oracle DBA? by Rob Horrocks
A lot of this is down to the licensing cost and structure which is probably the main reason SQL Server became more and more popular up until 2008, when Microsoft, for some crazy reason decided to inline their costs with Oracle and shot themselves in the foot.
Now both Oracle and SQL Server have taken a huge hit in this area. Microsoft believe their answer is to force people to Azure as the cheaper option but they don’t seem to realise that not everyone is ready for cloud based solutions, and open source solutions still exist and are continuing to mature.
I think Microsoft have also fallen into the trap of believing customers are stuck with what they have and feel they can squeeze everyone for the extra money but that’s not the case, and more and more customers are now looking for alternative solutions.
↧
↧
Comment on What is the future for an Oracle DBA? by John Hallas
Nice to get a view from a different RDBMS perspective – thanks Rob
↧
Comment on What is the future for an Oracle DBA? by John Hallas
Wow – proper rant mode. I like it 🙂
I hear where you are coming from – managing a large Data Warehouse where a change in plan can cause a job to overrun by several hours I am fed up of explaining to management that across our database estate the optimizer is probably making 100,000 choices a week and gets very few completely wrong.
In many ways the Rule based method was much more predictable
As a company who has a lot of stores we see some variance if a new store has been added but we also own manufacturing plants and if we add one of them in we see a significant change in plans as we might only have 5 and we add a sixth one in.
↧
Comment on What is the future for an Oracle DBA? by Dom Brooks
Aye… there’s a lot of pent up frustration currently.
Personally, I’m trying to branch out more into cloud strategies and developing in angularjs and python, etc but it doesn’t stop me getting frustrated about my true love…
↧
Comment on What is the future for an Oracle DBA? by Dom Brooks
It might seem like the rant about policies is off topic but I see it as just other nails in the same long-term coffin for Oracle.
↧
↧
Comment on What is the future for an Oracle DBA? by Martin Cassidy
John
Interesting article [per usual] and not an uncommon discussion point in many of the companies I’ve consulted through.
The “death of the DBA role” has been prophesized for many years now, in fact Oracle 9i was pumped as the “shrink wrapped DB solution” to allow non-techs run databases and we all know how well that worked out for organisations who tried to go it alone with inexperienced tech people.
The main thing I’ve noticed on my adventures with Oracle [7.1 onwards] is that the more that people believe the sales hype and try to simplify these processes, the more technical the solution underneath needs to be – “all things to all people” is a hard trick to pull off. If all applications were generic running on a vanilla patch level with predictable IO requirements along with consistent requirements, then SaaS/DaaS is an ideal solution SO long as all security requirements and performance spikes are handled within the vanilla options and limits these offerings work are limited by.
Move to a more “organic” flow of larger enterprise requirements and suddenly the SaaS/DaaS becomes slightly less of an obvious choice and then mix in the licencing costs and reusability of licences [Dev v Test v Perf v UAT v OAT v Prod V DR] and suddenly the choice isn’t so clear cut. If you then look at environments held to higher security standards [think government or fintech/trading, etc] and escalated costs of the models above, then you are back at the “horses for courses” point.
Oracle’s strength/weakness is that it provides to a wide range of requirements above a certain price point for its Enterprise solution. Under that price point [or near it] then other solutions start to bear fruit esp when functionality costs [partitioning, encryption, etc.] are explained to business owners. Solutions such as SQL Server, MySQL, Hadoop, MongoDB, MariaDB, NoSQL, etc all suddenly start fitting niches that the larger Enterprise solution is too expensive for. Once you compare these to Oracle Standard Edition then suddenly the cost factors are closer so you start looking at the other costs associated with DB ownership –resilience, reliability but primarily SUPPORT. If your first line of support is google/forum/occasionally manned ticket desks/etc then suddenly your cost saving on licencing needs to seriously be weighed up for the cost of outage duration that may be involved when there is no P1 support available 24/7.
I’m not saying Oracle doesn’t have its fault and I’m in no way a fanbois – I’ve experience in a wide range of industries and small to large companies where Oracle hasn’t been the DB of choice for a variety of reasons – but it is the market leader for a reason. Oracle’s product choices offered along with the support tiers available make it a smart choice for Enterprise class service – I avoid using the term “large database” as that can be exceedingly misleading as I remember 50Gb being considered a large database and now 200Tb considered a reasonable sized data warehouse. The main thing is that over the last 20+ years, every time a major player in software has dominated a market, it left niche players room to get established and grow, forcing the majors to either up their game or fall by the wayside. In all of this, technical people were needed and whilst demand hit peaks and troughs, data management was always needed and as such, the DBA role was always required.
In the 1990’s the DBA role was mainly command line driven with crontab type entries used to schedule routine tasks. Roll forward 20+ years and even before Cloud, the DBA role requires the candidate to understand application layer interactions as well as web tier implications for data security, role based access and how this all can be driven through a GUI as well as command line.
In summation, I think that whilst more generic interfaces and generic task management will be prevalent, the ability for a DBA to involve themselves at the technical ground level and deal with the unexpected results from rapidly changing software, will leave any organisation deploying enterprise class solutions with a mandatory requirement for appropriately skilled DBAs. If only from a risk mitigation side of the equation, having the ability to know when a vendor is pulling the wool over your eyes will still be as critical in 20 years as it was 20 years ago.
Cheers
Martin
↧
Comment on What is the future for an Oracle DBA? by John Hallas
What a well put together response Martin. I am very tempted to dedicate my next blog entry to looking at what you have said in more detail.
↧
Comment on What is the future for an Oracle DBA? by Manoj Gorai
Hi John,
This is really nice post and i would like to follow your post.
Regards,
Manoj
↧
Comment on What is the future for an Oracle DBA? by Dave
Great post and discussion, John! My client has continued to push away from Oracle solutions due to licensing costs, as like so many others. We’ve trying AWS, Hadoop, MongoDB, pretty much anything that might work for a particular solution which would save on licensing costs.
For the bigger corporations/IT departments, I expect that what will happen is a “near” conversion to another DBMS, rarely a full, organization-wide conversion. It’s just too hard and rarely cost effective to do this for everything. I’ve seen this over and over. How many people out there are tons of 12c installations yet have a few 10g or 9i stragglers? We have 4 x 12c OEM environments yet 2 more 11g. Why? Because we have x number of applications on 10g / 9i running RHEL4.6 or earlier that we can’t convince to even upgrade the OS so we can install a 12c agent.
Another thing that comes to mind goes back to those of us being in the IT workforce for long periods of time. You end up seeing patterns over and over and you know that eventually the industry will “correct” itself. In the late 80’s / early 90’s there was a huge push to everything being client-server, no more big iron. Then managing all those small to mid-sized hosts didn’t fit the bill and the market opened up for Starfire (Sun) and Wildfire (DEC) machines. Then it went back to smaller hosts. Then it was bigger solutions with large clusters. Now cloud with huge resources. Nearly all of those change in solutions were about licensing costs. The thing is, it’s not like suddenly everything is going to find some secret way to avoid licensing costs and vendors will never realize this. That will all correct itself.
Just my non-specific, fluffy, generalized opinion.
↧
↧
Comment on Downgrading a RAC database from 11.2.0.4 to 11.2.0.3 by Manoj Gorai
Thanks John for sharing the steps..
↧
Comment on Downgrading a RAC database from 11.2.0.4 to 11.2.0.3 by tranbinh48ca - Xứ giả truyền "lửa" công nghệ Oracle database
Good the article. Tks so much 🙂
↧
Comment on What is the future for an Oracle DBA? by Web Development
Move to a more “organic” flow of larger enterprise requirements and suddenly the SaaS/DaaS becomes slightly less of an obvious choice and then mix in the licencing costs and reusability of licences [Dev v Test v Perf v UAT v OAT v Prod V DR] and suddenly the choice isn’t so clear cut. We have 4 x 12c OEM environments yet 2 more 11g.
↧
Comment on Invisible Indexes – a real world example and a bit of LogMiner by lotharflatz
Unfortunately it seems the opt_param hint does not work with ‘OPTIMIZER_USE_INVISIBLE_INDEXES’
↧
↧
Comment on Invisible Indexes – a real world example and a bit of LogMiner by Dom Brooks
Good spot Lothar – see /*+ use_invisible_indexes */ hint instead.
↧
Comment on What is the future for an Oracle DBA? by ardalionanguiano
Move to a more “organic” flow of larger enterprise requirements and suddenly the SaaS/DaaS becomes slightly less of an obvious choice and then mix in the licencing costs and reusability of licences [Dev v Test v Perf v UAT v OAT v Prod V DR] and suddenly the choice isn’t so clear cut. Move to a more “organic” flow of larger enterprise requirements and suddenly the SaaS/DaaS becomes slightly less of an obvious choice and then mix in the licencing costs and reusability of licences [Dev v Test v Perf v UAT v OAT v Prod V DR] and suddenly the choice isn’t so clear cut.
↧
Comment on Downgrading a RAC database from 11.2.0.4 to 11.2.0.3 by sureshballipati
Hi John, It would be more helpful if you could mention the reasons for downgrading the database alone.
↧