RHEL: Figuring out CPUs, Cores and Hyper-Threading

matheusboesing Leave a comment

Hi all!
It’s a recurrent subject, right? But no one is 100% sure to how figure this out… So, let me quickly show you my way:

– Physical CPUs (sockets):

[root@mysrvr ~]# grep -i "physical id" /proc/cpuinfo | sort -u | wc -l
2
[root@mysrvr ~]# dmidecode -t processor |grep CPU
        Version: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
        Version: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz

So, 2 physical CPUs.

– Physical Cores

[root@mysrvr ~]# egrep -e "core id" -e ^physical /proc/cpuinfo|xargs -l2 echo|sort -u
physical id : 0 core id : 0
physical id : 0 core id : 1
physical id : 0 core id : 2
physical id : 0 core id : 3
physical id : 1 core id : 0
physical id : 1 core id : 1
physical id : 1 core id : 2
physical id : 1 core id : 3

Each one of Physical Processors has 4 cores.
So, there is two quad-cores. This way, we have 8 cores at all.

– Logical CPUs

[root@mysrvr ~]# grep -i "processor" /proc/cpuinfo | sort -u | wc -l
16

Ok, so we have cores in double.
This means we have Hyper-Threading (technology by Intel Processors).

Not so hard, right?

Those links are similar and quite cool to understand the concepts:
https://access.redhat.com/discussions/480953
https://www.redhat.com/archives/redhat-list/2011-August/msg00009.html
http://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html

x$kglob: ORA-02030: can only select from fixed tables/views

matheusboesing Leave a comment

Hi all!
While selecting on x$kglob with DBA credentials hanging on:

SQL> select count(*) from sys.x$kglob;
ERROR at line 1:
ORA-00942: a tabela ou view não existe

But with sys it succeed. Ok, let’s grant privilege:

SQL> grant select on sys.x$kglob to dba;
grant select on sys.x$kglob to dba
*
ERROR at line 1:
ORA-02030: can only select from fixed tables/views

What a hell! I couldn’t grant it any way!
So the MCGayver solution was:

Continue reading →

Saving database space with ASSM

maiqueldc Leave a comment

It’s good way reclaim WASTED space from tables and index using  the Segment Advisor.

To perform an database reclaim procedure using Automatic Segment Space Management (ASSM) it is preferred to create tablespaces with below option:

grepdb> CREATE TABLESPACE HR
DATAFILE '+GREPORADG/'
SIZE 10M EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

Only tablespaces with segment space auto are eligible to Segment Advisor.

To manually run the Segment Advisor on OEM:

guid-65f07e4f-0482-47df-bdf9-8d34b625093a-default

It will save some database storage area, and make it more effective cause by LHWM/HHWM.

Searching entries on Alert.log: A Better Way

matheusboesing Leave a comment

Hi all!
As the oldest readers know, someday I had to found some entries in the alertlog and I had a really big log. So I jerrry-ringed some scripts for grepping alert with auxiliar files and etc.
I can see the posts here: Grepping Alert by Day  and Grepping Entries from Alert.log.

So… They are functional, but probably the worst ways to get it. I didn’t know and was innocent to not search by the view x$dbgalertext.
There is also possible to write on alert through the procedure SYS.DBMS_SYSTEM.KSDWRT.

Ok, so let me fix this situation with theese two good guys: @write_alert and @find_alert

Continue reading →

PL/SQL Developer Taking 100% of Database CPU

matheusboesing Leave a comment

When using PL/SQL Developer (Allround Automations), a internal query is taking a lot of cpu cycles on database server (100% of a CPU).
Is this your problem? Please check if the query is like this:

select s.synonym_name object_name, o.object_type
from sys.all_synonyms s,
sys.all_objects o
where s.owner in ('PUBLIC', user)
and o.owner = s.table_owner
and o.object_name = s.table_name
and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE')

It’s caused by the Describe Context Option of Code Assistant. To disable it:
Tools > Preferences > Code Assistant and disable the “Describe Context” option.

Continue reading →