Tuesday, 23 December 2014

AIX LPAR missing hdisk after vios reboot SOLVED

In case that you are doing routine checkup of your LPAR's on IBM pSeries, you probably are checking status of your LPAR OS disks or volume group from time to time.
To check status of your volume group hdisks use this

root@aix-server> [/]  lsvg -p roottvg
rootvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk0                   missing                    546               4                 00..00..00..00..04
hdisk1                   active                       546               0                 00..00..00..00..00

 
As you can see one of hdisk is missing! And you start to panic! "OMG, hdisk is missing, where, how, when?!?!"

There is no place for panic. You will see that one of your disks is missing only after you have restarted one of your VIOS. In are case there is two VIOS. hdisk0 is from first VIOS, hdisk1 is from second VIOS. These two hdisk is creating volume group called rootvg.

How to fix this missing hdisk state?
All you need to do is to activate.  

root@aix-server> [/] varyon rootvg

This will activate your volume group rootvg. After this you will see both of your hdisk as active!
Why this is important? Because of this:

When a volume group is activated, physical partitions are synchronized if they are not current.

But there is one case when you can't make your hdisk active without making additional changes! In this case, after you execute varyon command, error will be prompted and you won't be able to make your hdisk active!

root@aix-server> [/] varyon rootvg
varyonvg: Cannot varyon volume group with an active dump device on a missing physical volume. Use sysdumpdev to temporarily replace the dump device with /dev/sysdumpnull and try again.

So, as error said active dump device is on missing physical volume hdisk0.(I will not explaind here what system dump device is) How to change this? First we will list status of sysdump devices.

root@aix-server> [/]  sysdumpdev -l
primary              /dev/lg_dumplv
secondary            /dev/sysdumpnull
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    FALSE
dump compression     ON







From here we can see, that primary device is located on /dev/lg_dumplv and secondary device is /dev/sysdumpnull. In error message, active dump device is actually primary dump device in sysdumpdev -l. So we need to change that.

root@aix-server> [/] sysdumpdev -p /dev/sysdupmnull

List again sysdump devices.

root@aix-server> [/]  sysdumpdev -l
primary            
/dev/sysdumpnullsecondary            /dev/sysdumpnull
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    FALSE
dump compression     ON


Now execute activation of volume group.


root@aix-server> [/] varyon rootvg

root@aix-server> [/] 
root@aix-server> [/]  lsvg -p rootvg
rootvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk0                         active            546                    4             00..00..00..00..04
hdisk1                         active            546                    0             00..00..00..00..00


As you can see now, both hdisk are active now.
Now, change back you primary dump device

root@aix-server> [/] sysdumpdev -p /dev/lg_dumplv

Thursday, 11 December 2014

RH6 and pdksh issue - SOLVED!

In case that you need to install pdksh package in your Red Hat 6, you will see something like this

# yum install pdksh
Loaded plugins: product-id, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Install Process
No package pdksh available.
Error: Nothing to do


Hm... strange isn't it?

Your issue is this

Not able to install pdksh on Red Hat Enterprise Linux 6

Explanation is really simple

The RHEL 6 provides mksh which is the advanced version of pdksh package. Install mksh instead pdksh

Solving it goes like this

#yum install mksh

Problem solved!

Tuesday, 2 December 2014

mysql VALUES LESS THAN value must be strictly increasing for each partition SOLVED!

In case that you are doing reorganization of your mysql table (I talk about it in my previous posts) you may run in to this error message

ERROR 1493 (HY000) at line 1: VALUES LESS THAN value must be strictly increasing for each partition

When I reorganise partitions I like to do in from OS, something like this

server# mysql Syslog < reorganize.txt

where reorganise.txt is mysql commands that look like this

server# cat reorganise.txt
alter table SystemEvents reorganize partition p2014 into
 ( partition p20141201 values less than (to_days('2014-12-01')),
   partition p20141202 values less than (to_days('2014-12-02')),
   partition p20141203 values less than (to_days('2014-12-03')),
   partition p20141204 values less than (to_days('2014-12-04')),
   partition p20141205 values less than (to_days('2014-12-05')),
   partition p20141206 values less than (to_days('2014-12-06')),
   partition p20141207 values less than (to_days('2014-12-07')),
   partition p20141208 values less than (to_days('2014-12-08')),
   partition p20141209 values less than (to_days('2014-12-09')),
   partition p20141210 values less than (to_days('2014-10-10')),
   partition p20141211 values less than (to_days('2014-12-11')),
   partition p20141212 values less than (to_days('2014-12-12')),
   partition p20141213 values less than (to_days('2014-12-13')),
   partition p20141214 values less than (to_days('2014-12-14')),
   partition p20141215 values less than (to_days('2014-12-15')),
   partition p20141216 values less than (to_days('2014-12-16')),
   partition p20141217 values less than (to_days('2014-12-17')),
   partition p20141218 values less than (to_days('2014-12-18')),
   partition p20141219 values less than (to_days('2014-12-19')),
   partition p20141220 values less than (to_days('2014-12-20')),
   partition p20141221 values less than (to_days('2014-12-21')),
   partition p20141222 values less than (to_days('2014-12-22')),
   partition p20141223 values less than (to_days('2014-12-23')),
   partition p20141224 values less than (to_days('2014-12-24')),
   partition p20141225 values less than (to_days('2014-12-25')),
   partition p20141226 values less than (to_days('2014-12-26')),
   partition p20141227 values less than (to_days('2014-12-27')),
   partition p20141228 values less than (to_days('2014-12-28')),
   partition p20141229 values less than (to_days('2014-12-29')),
   partition p20141230 values less than (to_days('2014-12-30')),
   partition p2014 values less than (MAXVALUE));

It look good right? But when I execute it error message appears.

server# mysql Syslog < reorganize.txt
ERROR 1493 (HY000) at line 1: VALUES LESS THAN value must be strictly increasing for each partition

So I check again my reorganize.txt file. It looks good.
I could not see the error. But there was an error!
server# cat reorganize.txt
alter table SystemEvents reorganise partition p2014 into
 ( partition p20141201 values less than (to_days('2014-12-01')),
   partition p20141202 values less than (to_days('2014-12-02')),
   partition p20141203 values less than (to_days('2014-12-03')),
   partition p20141204 values less than (to_days('2014-12-04')),
   partition p20141205 values less than (to_days('2014-12-05')),
   partition p20141206 values less than (to_days('2014-12-06')),
   partition p20141207 values less than (to_days('2014-12-07')),
   partition p20141208 values less than (to_days('2014-12-08')),
   partition p20141209 values less than (to_days('2014-12-09')),
   partition p20141210 values less than (to_days('2014-10-10')),
   partition p20141211 values less than (to_days('2014-12-11')),
   partition p20141212 values less than (to_days('2014-12-12')),
   partition p20141213 values less than (to_days('2014-12-13')),
   partition p20141214 values less than (to_days('2014-12-14')),
   partition p20141215 values less than (to_days('2014-12-15')),
   partition p20141216 values less than (to_days('2014-12-16')),
   partition p20141217 values less than (to_days('2014-12-17')),
   partition p20141218 values less than (to_days('2014-12-18')),
   partition p20141219 values less than (to_days('2014-12-19')),
   partition p20141220 values less than (to_days('2014-12-20')),
   partition p20141221 values less than (to_days('2014-12-21')),
   partition p20141222 values less than (to_days('2014-12-22')),
   partition p20141223 values less than (to_days('2014-12-23')),
   partition p20141224 values less than (to_days('2014-12-24')),
   partition p20141225 values less than (to_days('2014-12-25')),
   partition p20141226 values less than (to_days('2014-12-26')),
   partition p20141227 values less than (to_days('2014-12-27')),
   partition p20141228 values less than (to_days('2014-12-28')),
   partition p20141229 values less than (to_days('2014-12-29')),
   partition p20141230 values less than (to_days('2014-12-30')),
   partition p2014 values less than (MAXVALUE));

When I change value from 2014-10-11 to 2014-12-11(as it should be in the first place) everything worked perfectly!!!

Problem was like error messages said that there was partition that did not have increasing value to_days from previous partition. If this could happen then it would be possible to have not time consistent values in your partition tables.