Netapp Not able to access CIFS shares

 We May not be able to access CIFS shares ( including C$ and ETC$ ) on a New Filer I have come across this issue and i tried all possible ways to figure out the cause and finally i was able to fix the issue, 

The reason is when you run CIFS SETUP on your filer it will create a user called "PCUSER"  ( All windows users will be mapped to this users while accessing the shares on the filer )  , you can check it from the below command your file should be similar to below

FAS3220> rdfile  /etc/passwd

root : : 0 : : : / :
pcuser : : 65534 : 65534 : : / :
nobody : : 65534 : 65534 : : / :
ftp : : 65533 : 65533 : FTP Anonymous : /home/ftp :


For some reason  it does not create the user pcuser and i have noticed the /etc/passwd was empty so all what i did is to copy the /etc/passwd from one of my old filers and don't forget to run source command after copying

FAS3220> source  /etc/passwd

Once done you should be able to access you shares

Happy Knowledge Sharing :) 

Migrating a root Volume in Netapp

  Please remember that moving a root volume requires a reboot of the controller.  
Therefore, i suggest to complete this activity in your Maintenance windows. 

It is always good to have a snapshot created before starting any migrations 


FASProd>snap create -V vol0 vol0_snap


 1.       Disable the cluster:  

FASProd>cf disable

2.       Check the size of current vol0:  

FASProd>df -Vh  vol0

3.       Create a new root volume on destination aggr:    

FASProd>vol create  vol0_new  dest_aggr  <SIZE>

4.       Copy the data to the new volume:

FASProd> ndmpcopy /vol/vol0  /vol/vol0_new ( Can also use Vol Copy )

 5.       Once copy is done now Rename the old root volume: 

FASProd>vol rename vol0 vol0_old

6.       Rename the new root volume:  

FASProd>vol rename vol0_new vol0

7.       Now change the new vol0 to be used as root volume 

FASProd> vol options vol0 root

8.       Reboot the controller:  

FASProd>reboot

9.       Confirm the destination aggr now hosts the root vol0:  

FASProd>vol status vol0  

10.   Once confirmed proceed to Offline and destroy the old volume

FASProd> vol offline vol0_old  

FASProd> vol destroy vol0_old

Now i am a NTSP ( Nimble Technical Sales Professional )

Knowing what is Vmware Vcenter, ESXi, Vsphere

I was really confused with the terms Vsphere , Vcenter and ESXi and i have thought to write up the difference so that it might help someone at some point of time

What is vSphere ?

vSphere is suite of products packaged shipped by VMware virtualization company, which includes products. Like VMware ESXi hypervisor, VMware vCenter Server, etc.

VMware ESXi ?

ESXi or hypervisor is bare metal OS which virtualizes x86 server hardware. You use ESXi ( OS ) installation  media to install OS on top of hardware just like you install any other OS like Windows or Linux

Once you have VMware ESXi installed on a x86 server hardware I is ready to virtualized. What does it mean ? - It means you can now use same server to create , configure, run more than one virtual machines and install required Operating systems within Virtual Machines they are referred as Guest Operating systems which could be Windows or Linux etc

 What is vCenter ?

 

Vcenter is another Vmware product used to manage one or more ESXi servers comes in the Vsphere software package.

Netbackup Vmoprcmd Cobra Communication Error

If you have your Netbackup Master Server Version 7.6 and your media server ( We had 7.0.1 ) version lower than master version you may face the error while you run the command Vmoprcmd 

 Even the compatibility matrix says 7.6 is compatible with 7.0.1 but still we have faced the below error as soon as we upgraded the master server from 7.0.1 to 7.6.0.1,

Cobra Communication Error 

Solution :-  Is to Upgrade Media server also from 7.0.1 to 7.6.0.1 to fix this issue.

Netbackup Oracle backup Error 6 On HP-UX Client

One of our Oracle DB backups were failing with error 6 which is a generic error for DB backups using Netbackup and from the error log i have found

Errors in file /OraBase/admin/Test50/bdump/Test50_j000_29761.trc:

ORA-12012: error on auto execute of job 661138

ORA-00257: archiver error. Connect internal only, until freed.




Error:- ORA-00257: archiver error. Connect internal only, until freed.

Solution:- 

And i see this is moreover Oracle Side to troubleshoot rather the Netbackup side and after a small research i have found the solution is to move some of the archive logs 

--> find the location of Archive destination by
 show parameter archive_dest
 
 lets say it provide  LOCATION=/Test50/oradata/mydb/arch

-->  move some files to some other location using os command
 cd /Test50/oradata/mydb/arch
 mv /Test50/oradata/mydb/arch/* /Test5/oradata/mydb/arch-bkp/
 
If you want to do it from RMAN , try as below.

rman target /

RMAN> backup archive log all format '/Test50/oradata/mydb/arch-bkp';

RMAN> delete archive until time 'trunc(sysdate)';

Error:- ORA-12012: error on auto execute of job 7863452

Solution:- 

The underlying table required as part of one of the schedule maintenance tasks has invalid values. 
The related table is Test50.Testing_Base. 

After taking a look at the job log we see the failed execution attempts:

SQL> select log_date,status from dba_scheduler_job_run_details 
     where job_name='Test50_DBTesting_JOB';

LOG_DATE                              STATUS
------------------------------------- ------------------------------
11-FEB-14 10.00.07.3668 AM -06:00    FAILED
04-FEB-14 08.00.05.59665 AM -06:00   FAILED


2 rows selected.

Solution

Check the invalid values on the table and remove them.

SQL> select * from Test50.Testing_Base;

      DBID INSTANCE_NAME    BASELINE_ID BSLN_GUID                        TI A STATUS           LAST_COMPUT
---------- ---------------- ----------- -------------------------------- -- - ---------------- -----------
4056791929  orcl                       0 24T6YH78JNSHDT89ONSNS09Q2NND8728 NW N ACTIVE           140917:2200
4052355478  ORCL3                      0 12MDNSIdGAJKW474IETJBESGJH539930 ND Y ACTIVE           141022:2000


As we can see the above orcl is corrupted , Now we proceed to delete it.


The corrupt row can be removed as below.


SQL> DELETE FROM Test50.Testing_Base WHERE INSTANCE_NAME ='orcl';

1 row deleted.

SQL> commit;

Commit complete.

Manually re-execute the job and check the execution log, it must show the job executed successfully.  It takes a couple of minutes after execution to show the results in the log table.

SQL> exec dbms_scheduler.run_job('Test50.Testing_Base',false);
PL/SQL procedure successfully completed.


The issue was fixed, validate it by querying

SQL> select log_date,status from dba_scheduler_job_run_details 
     where job_name='Test50.Testing_Base';

LOG_DATE                              STATUS
------------------------------------- ------------------------------
14-FEB-14 11.00.07.315077 AM -06:30   FAILED
15-FEB-14 11.00.05.595559 AM -06:30   FAILED
17-FEB-14 03.41.20.714453 Am -06:30   SUCCEEDED

Now try re-run the job it should be successful :)