Shrinking thin provisioned ASM disks results in smaller diskgroup

Just the other day I ran out of space on my laptop. That’s what you get with these “tiny” SSD’s nowadays. Anyway, when looking around where I had most data stored I found that an ASM disk in a VM was taking most of the space. This disk, as all my disks for VM’s, was thin provisioned. Usually I use some zero fill utillity overwrite the free space in a think provisioned disk so VirtualBox can shrink the disk. But this sounded risky to me for ASM, also those utilities need an ext filesystem.

Some googling learned me that I wasn’t the first one with this issue. Oracle actually supports a tool for this called ASRU: ASM Storage Reclamation Utility (ASMSRU must have been to long). So, easy comes easy does. Download the utility, fire it up ( ./ASRU -a sysasm DATA ) wait for some time and *presto* . 30 GB back of my 256 GB SSD. How cool is that!

Until about a week later I run into space issues in ASM in the VM I mentioned before. My ASM disk group was full. That sounded hilarious to me, since it was on a 40GB disk (checked it in VirtualBox and yes: still 40GB). Then I remembered ASRU.

Checking the v$asm_diskgroup showed something interesting:

SQL> SELECT name, total_mb, usable_file_mb FROM v$asm_diskgroup;

NAME       TOTAL_MB  USABLE_FILE_MB
--------- --------- ---------------
DATA          10090            1288

So, ASRU actually not only shrunk the disk, it also resided the disk group in ASM. Now how about that? I didn’t read any statement in the README file saying I had to resize my diskgroup after running ASRU….

SQL> ALTER DISKGROUP data RESIZE ALL;

Diskgroup altered.

SQL> SELECT name, total_mb, usable_file_mb FROM v$asm_diskgroup;

NAME       TOTAL_MB  USABLE_FILE_MB
--------- --------- ---------------
DATA          40954           32152

So, if you happen to use ASRU, don’t forget to resize your diskgroup or you will live in interesting times.

Hopes this helps.

storeUserConfig caveats

While creating a small startup script for nodemanager on my test setup (to prevent me from having to start nodemanager manually all the time) I figured storing the clear text password in the script was a bad practice. Therefore I wanted to use the storeUserConfig command in WLST to store the username and password in a user configuration file and an associated key file.

You would expect that to be not too exciting, but some caveats arose. First you have to connect nodemanager

wls:/offline> nmConnect('nodemanager','Welkom01','wls1.area51.local',5556,'hs_test');
Successfully Connected to Node Manager.

Then you can store the configuration:

wls:/nm/hs_test> storeUserConfig(userConfigFile='/u01/app/oracle/admin/nodemanager/nodemanager.config', userKeyFile='/u01/app/oracle/admin/nodemanager/nodemanager.keyfile');
Currently connected to Node Manager to monitor the domain hs_test.
You will need to be connected to a running WLS or Node Manager to execute this command

mmmm… that was unexpected. Seems you have to pass an extra argument to mention that you are only connected to the nodemanager

storeUserConfig(userConfigFile='/u01/app/oracle/admin/nodemanager/nodemanager.config', userKeyFile='/u01/app/oracle/admin/nodemanager/nodemanager.keyfile',nm='true');
Currently connected to Node Manager to monitor the domain hs_test.
Creating the key file can reduce the security of your system if it is not kept in a secured location after it is created. Do you want to create the key file? y or ny
The username and password that were used for this WebLogic NodeManager connection are stored in /u01/app/oracle/admin/nodemanager/nodemanager.config and /u01/app/oracle/admin/nodemanager/nodemanager.keyfile .

Now that is all cool, next if you should be able to connect to nodemanager without specifying a username and password:

wls:/offline> nmConnect(userConfigFile='/u01/app/oracle/admin/nodemanager/nodemanager.config', userKeyFile='/u01/app/oracle/admin/nodemanager/nodemanager.keyfile', host='wls1.area51.local', port=5556, domainName='hs_test');
Connecting to Node Manager ...
Traceback (innermost last):
File "", line 1, in ?
File "", line 123, in nmConnect
File "", line 648, in raiseWLSTException
WLSTException: Error occured while performing nmConnect : Cannot connect to Node Manager. : Access to domain 'hs_test' for user 'weblogic' denied
Use dumpStack() to view the full stacktrace

Ehhrmm… that sort of sucks. Seems that the username is defaulted to weblogic all of the sudden. Well that sucks, that implies that you cannot use the stored configuration if your username is not weblogic (like in my case). Bummer… (I just hope I am wrong)

Hope this helps.

And thanks to Peter van Nes to learn me how to use the sourcecode setting in wordpress.

BEA-000362, incomplete error

While setting up Service Migration in a small test setup on my laptop, I ran into this error:

<BEA-000362> <Server failed. Reason: There is either a problem contacting the database or there is another instance of ManagedServer_2 running>


It took me some time to figure out what the exact problem was. If the message was complete like this, problem solving would have been easier:

<BEA-000362> <Server failed. Reason: There is either a problem contacting the database or there is another instance of ManagedServer_2 running or the leasing table is missing from the database>


You can find the DDL for the default leasing table, called active, in a file called leasing.ddl which is located at $MW_HOME/wlserver_10.3/db/oracle/920 . If you happened to have changed the name for the leasing table, you obviously have to modify the leasing.ddl script accordingly.

Hope this helps.