Wrong count of CPU on HP-UX 11.31
We have two identical machines, two identical HW resources, two identical configurations but there is one significant difference.
Output from machine A:
$ uname -srm
HP-UX B.11.31 ia64
SQL> select CPU_COUNT_CURRENT,CPU_CORE_COUNT_CURRENT,CPU_SOCKET_COUNT_CURRENT,CPU_COUNT_HIGHWATER from v$license;
CPU_COUNT_CURRENT CPU_CORE_COUNT_CURRENT CPU_SOCKET_COUNT_CURRENT CPU_COUNT_HIGHWATER
----------------- ---------------------- ------------------------ -------------------
28 28 28
$ machinfo
CPU info:
8 Intel(R) Itanium 2 9100 series processors (1.6 GHz, 24 MB)
533 MT/s bus, CPU version A1
28 logical processors
# ioscan -kf | grep processor | wc -l
28
So everything seems to be fine (just output from v$license shows misleading info) and we've got 28 cores. No, it's not!
Output from machine B:
$ uname -srm
HP-UX B.11.31 ia64
SQL> select
CPU_COUNT_CURRENT,CPU_CORE_COUNT_CURRENT,CPU_SOCKET_COUNT_CURRENT,CPU_COUNT_HIGHWATER from v$license;
CPU_COUNT_CURRENT CPU_CORE_COUNT_CURRENT CPU_SOCKET_COUNT_CURRENT CPU_COUNT_HIGHWATER
----------------- ---------------------- ------------------------ -------------------
14 14 14
$ machinfo
CPU info:
8 Intel(R) Itanium 2 9100 series processors (1.6 GHz, 24 MB)
533 MT/s bus, CPU version A1
14 logical processors
# ioscan -kf | grep processor | wc -l
14
Machine A shows doubled amount of CPUs than on machine B. Both VPARs have 7x Intel Itanium 2 processors (2 cores each).
So that means the vPar has 14 CPU cores. Machine B shows correct info but A doesn't.
How to find correct information about CPUs in this case? We can use /sbin/vparstatus to clearly see that there are 14 cores assigned to vPar.
Machine A:
[Virtual Partition Resource Summary]
CPU Num Num Memory Granularity
Virtual Partition Name Min/Max CPUs IO ILM CLM
============================== ======= ==== ==== ========== ==========
DB1 1/ 24 14 7 512 512
Machine B:
[Virtual Partition Resource Summary]
CPU Num Num Memory Granularity
Virtual Partition Name Min/Max CPUs IO ILM CLM
============================== ======= ==== ==== ========== ==========
DB2 1/ 24 14 6 512 512
It is very important to know correct information, at least in two cases, performance (monitoring, tuning or troubleshooting) and for correct product licensing.
What is the difference between those two machines? The difference is that machine "B" has latest patches whilst machine "A" even it is patched but (according to swlist) certainly latest patches weren't used. Unfortunately I can't provide wich patch or bundle is fixing this problem for this moment but when I find it then I'll post it right here.
Update:
My theory was correct and the final answer is very simple - multithreading. This type of Itanium Processors have two threads for each core. You can set multithreading on partition level (this has been done on both of machines) and also on OS level by lcpu_attr and there was the difference.
You can verify the settings using kctune |grep lcpu.
So the conclusion is no matter what patches are installed in this case.
Share
Posted on Thursday, February 24, 2011 Comments [2]
Really (not) useful example
I was reading official PHP documentation few days ago. While searching around for some information I found something really surprising.
To be specific I found an example of using PDO::commmit() which was quite funny for me.
Few years ago I was wondering during code review where some (really bad) ideas come from. Now I finally understand because when we can see this really "useful" example in PHP official guide, so at least I don't need to wonder anymore.
I took the original code and changed it slightly to prepare the example for newcomers in this area for better understanding what's going on and why this example is bad.
Original code:
<?php
/* Begin a transaction, turning off autocommit */
$dbh->beginTransaction();
/* Change the database schema */
$sth = $dbh->exec("DROP TABLE fruit");
/* Commit the changes */
$dbh->commit();
/* Database connection is now back in autocommit mode */
?>
New code:
<?php
try {
$dbh = new PDO("oci:dbname=//nnn.nnn.nnn.nnn:1521/test", "usr", "pwd");
// Check contents of "fruit" table
echo "First check: ";
$sth = $dbh->prepare("SELECT id FROM fruit");
$sth->execute();
$err = $sth->errorInfo();
echo "<font color=\"red\">".$err[2]."";
while($row = $sth->fetch()) {
echo $row["ID"]."";
}
// ==== BEGIN OF ORIGINAL CODE ====
/* Begin a transaction, turning off autocommit */
$dbh->beginTransaction();
/* Change the database schema */
$sth = $dbh->exec("DROP TABLE fruit");
/* Replaced Commit to Rollback */
$dbh->rollback();
/* Database connection is now back in autocommit mode */
// ==== END OF THE ORIGINAL CODE ====
// check contents of "fruit" table again
echo "Second check: ";
echo "Second check: ";
$sth = $dbh->prepare("SELECT id FROM fruit");
$sth->execute();
$err = $sth->errorInfo();
echo "<font color=\"red\">".$err[2]."";
while($row = $sth->fetch()) {
echo $row["ID"] . "";
}
} catch(PDOException $e) {
echo $e->getMessage();
}
?>
So we have a table called namaed "FRUIT" which contains ten rows (increasing value from 1 to 10).
The script (as shown above) selects and shows all rows from table "FRUIT" then executes the original code and then selects all rows from "FRUIT" table again. There is just one difference in original code. I changed COMMIT to ROLLBACK for better understanding of uselessnes of the Original code shown in example on PHP.net documentation.
First check:
1
2
3
4
5
6
7
8
9
10
Second check:
OCIStmtExecute: ORA-00942: table or view does not exist(...)
So as we can see we did do DROP TABLE and even we rollbacked the transaction the table remains dropped. Yes, this is pretty correct behaviour as DROP TABLE is DDL statement and you can only rollback (or commit) DML statement (INSERT, UPDATE, DELETE, MERGE). So if ROLLBACK doesn't work thus it means we don't need to use COMMIT at all.
The second point is that DDL statement almost always does implicit commit before and after (I used the "almost" word because this is not true for all DDL statements for example for "ALTER SESSION" statement). So no matter we do before DDL it will be commited, so in case of possible rollback DML executed before DDL within a transaction will be not rollbacked.
There are couple of things or statements which could be used as example but they used the worst ever and created totally useless example.
Share
Posted on Friday, February 18, 2011 Comments [3]
Installation article for 11g Release 2 for Solaris 11 Express (2010.11)
Oracle killed the OpenSolaris project (fork of former OpenSolaris is now OpenIndiana - http://openindiana.org) and released Solaris 11 Express. So the new Solaris is officially out and comes with several very interresting features but I'll mention about few which user may facing to during his work with this version.
Root account is now Root role
In fact this thing is not new. RBAC was here for long but now it is the default. When you try to log on as the "root" user then logon will fail. So you can't to logon directly. You need to log on as non-root user and then execute "su -". For successfull logon via "su -" command you need to have granted "root" role otherwise you will get "Roles can only be assumed by authorized users" message.
Only first created user (you are creating it during installation) has this role granted by default. So for the other users root role needs to be granted. Example:
usermod -R root johndoe
Of course you can specify role (root role in this case) also during user creation. Example:
useradd -R root -m -d /export/home/johndoe johndoe
You may ask "Is there possibility to set old fashioned behaviour?" Yes, it is but be sure you really want to do that.
To enable login as root directly execute following command:
rolemod -K type=normal root
Also to enable connect using SSH and allow root login you need to change PermitRootLogin in SSH configuration and restart SSH service.
PermitRootLogin yes
and then
svcadm restart ssh
Done.
Some keywords for study: RBAC, sudo, pfexec, pf(shell name)
The home directory and default shell
Root role is not the only thing that first user will get.
When you create new user using following command:
useradd oracle
Assume that first account created (during installation) was "ivan". If you compare entries in /etc/passwd you will find one difference.
"ivan" account has /bin/bash as default shell and "oracle" has /bin/sh (which is symlink to ksh93 in fact).
For change of shell to Bash just use the usermod command:
usermod -s /bin/bash oracle
The second difference is that /home/oracle does not exist even if it is stored in /etc/passwd file.
When you try to create it manually you will get: "mkdir: cannot create directory `oracle': Operation not applicable".
You may delete the user and try to create it using -d an -m switch. In that case you will get:
"UX: useradd: ERROR: Unable to create the home directory: Operation not applicable.".
The answer for this is simple. You can't do that because /home directory is maintained by AutoFS.
Possible solutions (classic well known way):
1. Use different (existing) home directory. Example:
useradd -R root -m -d /export/home/johndoe johndoe
2. Modify /etc/auto_home add relevant entry for future user and then create it. Example:
echo "johndoe localhost:/export/home/&" >> /etc/auto_home
useradd -m -d /home/johndoe johndoe
Bugs and Fun
No, this is not name of some feature. This will be just light description of issues I was facing to during the installation of Oracle Database.
- 11.2.0.1 version doesn't know Solaris 11 OS. In fact it will install correctly also it is functional it just skips the prerequistes check step.
You need to download latest release 11.2.0.2 from My Oracle Support website.
- 11.2.0.2 version knows the Solaris 11 OS but during prerequisites check it requests to install non existing packages (replaced) packages i.e.: SUNWi1of and SUNWxwfnt (I belive there were replaced by SUNWfont-xorg-core and SUNWfont-xorg-iso8859-1 packages).
- 11.2.0.2 version requests to set LoginGraceTime 0 but I don't think this is a good idea even there is limit to max connections.
- There is lot of URLs to OpenSolaris website and lot of "OpenSolaris" texts in configuration files.
Installation article you can find here http://ivan.kartik.sk/oracle/install_ora11gR2_solaris11.html or in menu of this page. I belive that this paper will work also for last OpenSolaris versions and OpenIndiana (I wish long life to this project) as well.
Enjoy.
Share
Posted on Thursday, November 25, 2010 Comments [7]
Installation article for 11g Release 2 on Redhat,OEL and Centos 5
I prepared short installation HOWTO for Redhat and it's clones (Oracle Enterprise Linux and Centos). Installation on first two of them was fine without significant problems but Centos needs couple of workarounds which are the reason why I created this article. In fact there is not problem with Centos as it is same as RHEL and OEL but as Centos is not certified operating system OUI and some scripts makes complications during installation process. You might say "Use certified distribution", but there are lot of Centos users which don't want to use other distribution (for example because of missing free updates) or they don't use some of Virtual machines for Oracle. But in fact some of certified distributions aren't fully supported by the new Database release.
In case You are the Centos 5 user here are the fixes for successful installation of 11gR2:
1. Old good /etc/redhat-release and /etc/issue (Optional)
Solution which I posted years ago for 10gR1 release does not solve everything. Also modification of oraparam.ini (which was far better solution) does not solve anything.
But to be sure apply this settings (backup /etc/redhat-release and /etc/issue before) change existing value to
Red Hat Enterprise Linux Server release 5 (Tikanga)
2. Install fake redhat-release RPM file
OUI checks for presence of redhat-release package and if it is missing then it will skip the prerequisites verification process. Unfortunatelly there is centos-release package installed on system (Don't uninstall it!). I created fake centos-fake.noarch.rpm RPM package to solve this issue. If you don't trust to my packages (I fully understand this) You can build your own package using this
.spec file.
Install downloaded (built) package:
rpm -i centos-fake.noarch.rpm
Don't worry about package name, after installation it will appear as "redhat-release" in RPM database.
3. Solve the "ADVM/ACFS is not supported" issue
This workaround solves Oracle Database 11g Release 2 Grid Infrastructure installation (neccessary for ASM or RAC). In fact ASMFS is not needed for for ASM but in case you want to test this new feature this workaround will help you.
ASMFS feature is available only on Redhat and Oracle Enterprise Linux distribuion. So SUSE (SLES) is out of play at this moment (I won't speculate wh
y it so but modules are provided for RH and OEL kernel only) so as You can see not all certified distributions are supported equally.
During root.sh execution or ohasd initiation You could see one of these messages:
ADVM/ACFS is not supported on centos-release-5-4.el5.centos
ADVM/ACFS is not supported on centos-release-5-3.el5.centos
ADVM/ACFS is not supported on centos-release-5-2.el5.centos
ADVM/ACFS is not supported on centos-release-5-1.el5.centos
To workaround this use this simple fix (I suggest to to this before GRID installation):
echo "redhat-release-5Server-5" > /tmp/.linux_release
To prevent deletion or modification of .linux_release file I suggest to set immunitable flag:
/usr/bin/chattr +i /tmp/.linux_release
Note!: This workaround is working Redhat clones (OEL, Centos) only! It will be not working on other distros.
Now your Centos will appear for Oracle 11g R2 as certified distribution.
Full installation paper for all three distributions (including workarounds for Centos) You can find here or in menu of this page.
Share
Posted on Sunday, January 10, 2010 Comments [4]