RE: dbms_stats.gen_selmap

Hey. My friend Charley Muntz coded up the interpreter that ran on that computer. It ran navigation programs in about 15K bytes, so don’t complain they didn’t spit out the text version of the error alert.  

Doh. I realize you were observing that perhaps now, with stray Gigs of memory all over the place, they might give you the text message…  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael D O'Shea/Woodward Informatics Ltd Sent: Saturday, December 16, 2017 1:43 PM To: vishal_at_vishalgupta.com
Cc: martin.a.berger_at_gmail.com; Franck Pachot; Lothar Flatz; oracle-l_at_freelists.org Subject: AW: dbms_stats.gen_selmap  

1202

1202

1202

1202

1202

1202

1202

1202

1202

1202

1202

1202

1202  

What is a 1202 alarm/error ?  

Look it up in the documentation !  

There was not the computer memory available in 1969 to code up and store a proper alarm/error message. About 50 years since Apollo 11, the Oracle binary coded trace level number remains about as informative as the 1202 error.  

Goodness me.  

Mike  

http://www.strychnine.co.uk    

Am 16.12.2017 um 18:40 schrieb Vishal Gupta <vishal_at_vishalgupta.com>:  

Here are the trace level (upto 12.2 version).  

Trace Levels

1 = use dbms_output.put_line instead of writing into trace file

2 = enable dbms_stat trace only at session level

4 = trace table stats

8 = trace index stats

16 = trace column stats

32 = trace auto stats – logs to sys.stats_target$_log

64 = trace scaling

128 = dump backtrace on error

256 = dubious stats detection

512 = auto stats job

1024 = parallel execution tracing

2048 = print query before execution

4096 = partition prune tracing

8192 = trace stat differences

• 11.1 onwards

16384 = trace extended column stats gathering

• 11.2.0.2 onwards

32768 = trace approximate NDV (number distinct values) gathering

• 12.1 onwards

65536 = Online trace

131072 = Automatic DOP trace

262144 = System statistics trace

• 12.2 onwards

524288 = Advisor trace  

Regards,

Vishal Gupta  

From: <mailto:oracle-l-bounce_at_freelists.org> oracle-l-bounce_at_freelists.org [ <mailto:oracle-l-bounce_at_freelists.org> mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Martin Berger Sent: 15 December 2017 22:24
To: Franck Pachot
Cc: Lothar Flatz; <mailto:oracle-l_at_freelists.org> oracle-l_at_freelists.org Subject: Re: dbms_stats.gen_selmap  

Lothar,

Did you try to trace the dbms_stats activities? Jared Still has documented some trace levels here:

 <https://blog.pythian.com/options-for-tracing-oracle-dbms_stats/> https://blog.pythian.com/options-for-tracing-oracle-dbms_stats/  

hth

 Martin    

2017-12-15 15:14 GMT+01:00 Franck Pachot < <mailto:franck_at_pachot.net> franck_at_pachot.net>:

Hi Lothar,

It seems related to online statistics gathering, which makes sense during an insert append.

Regards,

Franck.  

On Fri, Dec 15, 2017 at 1:40 PM Lothar Flatz < <mailto:l.flatz_at_bluewin.ch> l.flatz_at_bluewin.ch> wrote:

We could trace it back to an insert /*+ append */. I did a little experiment. The call is actually related to dynamic statistics generation.

Am 15.12.2017 um 09:41 schrieb Lothar Flatz:
> Hi,
>
> this is a long running procedure on one of our DB's. According to
> Morgans Library it is an undocumented subprogram. Does anybody know
> what it does and when it is called?
>
> Regards
>
> Lothar
>

--




--
 <http://www.freelists.org/webpage/oracle-l> http://www.freelists.org/webpage/oracle-l

 



--
http://www.freelists.org/webpage/oracle-l