Sun achieves the Magic Number 50,000 on T5440 with Oracle Business Intelligence EE 10.1.3.4

Less than two months ago, Sun Microsystems published an Oracle Business Intelligence benchmark with the best single system performance of 28,000 concurrent BI EE users at ~75% CPU utilization. Sun and Oracle Corporation announced another Oracle Business Intelligence benchmark result today with two identical T5440 servers in the Oracle BI Cluster serving 50,000 concurrent BI EE users.

An Oracle white paper with Sun's 50,000 user benchmark results can be accessed from Oracle's Business Intelligence web.

The hardware specifications for each of the T5440s are similar to the hardware that was used in the prior benchmark effort on a single T5440 server. However this time the Presentation Catalog (also frequently referred as the Web Catalog) was moved to a T5220 server where the NFS server was running. Besides this the only other change from the earlier 28,000 user benchmark exercise is the addition of another T5440 to the test rig.

The following graph shows the scalability of the application from one node to four nodes to eight nodes running on T5440 servers.

Without further ado, here is the summary of the benchmark results along with their significance and some interesting facts:

• One of the major goals of this benchmark effort is to show the horizontal and vertical scalability of the application (OBIEE) by highlighting the superior performance and the resilience of the underlying hardware (T5440) and the operating system (Solaris). Needless to say the goal has been met.

• Another goal of this benchmark is to show decent number of concurrent BI EE users executing transactions with good response times. Since we already showed the maximum load that can be achieved on a single BI instance (7500 users) and on a single T5440 server running multiple BI instances (28,000 users), this time we did not attempt to get the peak number that can be achieved from the two T5440 servers in the benchmark environment. Now that there is an additional server in the test setup that is taking care of the Presentation Catalog and the database server, 2 * 28000 = 56,000 BI EE users would have been an achievable target -- but we opted to stop at the "magic" and the "respectable" number 50,000 instead.

• The entire benchmark run lasted for about 9 hours 45 minutes, and out of which 8 hours were the rampup hours where the 50,000 BI virtual users were logging into the application few users at a time. LoadRunner tool reported only 4 errors for the entire duration of the run; and there are zero errors in the 60 minute steady state period during which the statistics reported in the document were collected.

• Two Sun SPARC Enterprise T5440 servers each with 4 x 8-Core 1.6 GHz UltraSPARC T2 Plus processors delivered the best performance of 50,000 concurrent BI EE users at around 63% CPU utilization.

• The BI EE Cluster was deployed on two T5440 servers running Solaris 10 5/09 operating system. All the nodes in the BI Cluster were consolidated onto two T5440 servers using the free and efficient Solaris Containers virtualization technology.

• The Presentation Catalog was hosted on ZFS powered file system that was created on top of four internal Solid State Drive (SSD) disks. The Catalog was shared among all eight BI nodes in the cluster as an NFS share. One 8-Core 1.2 GHz UltraSPARC T2 processor powered T5220 server was used to run the NFS server. Due to the minimal activity of the database, Oracle 11g database was also hosted on the same server. Solaris 10 5/09 is the operating system.

• Solid State Drive (SSD) disks with ZFS file system showed significant I/O performance improvement over traditional disks for the Presentation Catalog activity. In addition, ZFS helped get past the UFS limitation of 32767 sub-directories in a Presentation Catalog directory.

• Caching was turned ON at the application server, which led to minimal database activity on the server. Note hat the caching mechanism was turned ON even in the prior benchmark exercise.

• The low end CoolThreads CMT Server T5220 and the mid-range T5440 server once again proved to be ideal candidates to deploy and run multi-thread workloads by exhibiting resilient performance when handling large number of simultaneous requests from 50,000 BI EE virtual users. T5220 handled large number of concurrent asynchronous read/write requests from eight different NFS clients.

• NFS v3 was configured at the NFS Server as well as at the NFS Client nodes. NFS version 4 is the default on Solaris 10, and it might have worked as expected. However a handful of bug reports prompted us to go with the more matured and less buggy version 3.

• 3283 watts is the average power consumption when all the 50,000 concurrent BI users are in the steady state of the benchmark test. That is, in the case of similarly configured workloads, the T5440 server supports 15.2 users per watt of energy consumed and supports 5,000 users per rack unit.

• A summary of the results with system-wide averages of CPU and memory utilization is shown below. The latest results are highlighted in blue color.

  #Vusers	Clustered	#BI Nodes	#CPU	#Core	RAM	CPU	Memory	Avg Trx Response Time	#Trx/sec
  7,500	No	1	1	8	32 GB	72.85%	18.11 GB	0.22 sec	155
  28,000	Yes	4	4	32	128 GB	75.04%	76.16 GB	0.25 sec	580
  50,000	Yes	8	8	64	256 GB	63.32%	172.21 GB	0.28 sec	1031

The topology diagram in the benchmark results white paper is almost illegible. Here is the original topology diagram that was inserted into the white paper.

Quite frankly I'm not very proud of this drawing -- but that's the best that I could come up with in a short span. Rather than showing the flow of communication between each and every component in the benchmark setup, I simplified the drawing by introducing a "black box" sort of thing - "private network" - in the middle, which protected the drawing from getting messy.

The following two-dimensional graph shows the CPU utilization patterns at all 3 nodes in the benchmark setup for the 60 minute steady state of the benchmark run. This graph was generated using the free GNUplot tool with sar data as the inputs.

And finally here is a quick summary of all the results that are published by different vendors so far with similar benchmark kit. Feel free to draw your own conclusions. All this is public information. Check the corresponding benchmark reports by clicking on the URLs under the "#Users" column.

Before you go, do not forget to check the best practices for configuring / deploying Oracle Business Intelligence on top of Solaris 10 running on Sun CMT hardware.

Related Blog Posts:
T5440 Rocks [again] with Oracle Business Intelligence Enterprise Edition Workload

Posted at 04:20AM Oct 10, 2009 by Giri Mandalika in Benchmarks  |  Comments[0]

T5440 Rocks [again] with Oracle Business Intelligence Enterprise Edition Workload

A while ago, I blogged about how we scaled Siebel 8.0 up to 14,000 concurrent users by consolidating the entire Siebel stack on a single Sun SPARC^® Enterprise T5440 server with 4 x 1.4 GHz eight-core UltraSPARC^® T2 Plus Processors. OLTP workload was used in that performance benchmark effort.

We repeated a similar effort by collaborating with Oracle Corporation, but with an OLAP workload this time around. Today Sun and Oracle announced the 28,000 user Oracle Business Intelligence Enterprise Edition (OBIEE) 10.1.3.4 benchmark results on a single Sun SPARC Enterprise T5440 server with 4 x 1.6 GHz eight-core UltraSPARC T2 Plus Processors running Solaris 10 5/09 operating system. An Oracle white paper with Sun's 28,000 user benchmark results is available on Oracle's benchmark web site.

Some of the notes and key take away's from this benchmark are as follows:

• Key specifications for the Sun SPARC Enterprise T5440 system under test are: 4 x UltraSPARC T2 Plus processors, 32 cores, 256 compute threads and 128 GB of memory in a 4RU space.

• The entire OBIEE solution was deployed on a single Sun SPARC Enterprise T5440 server using Oracle BI Cluster software.

• The BI Cluster was configured with 4 x BI nodes. Each of those BI nodes were configured to run inside a Solaris Container.

  1. Each Solaris Container was configured with one physical processor (that is, 8 cores or 64 virtual cpus), and 32 GB physical memory.

  2. Each BI node was configured to run BI Server, Presentation Server and OC4J Web Server

  3. Two of the BI nodes have the BI Cluster Controller running (primary & secondary)

  4. One out of four Containers was sharing CPU and memory resources with Oracle 11g RDBMS and the host operating system that are running in the global zone

• Caching was turned ON at the application server, which led to minimal database activity on the server.

  1. In other words, one can use these results only to size the hardware requirements for a complete BI EE deployment excluding the database server.

  2. All the OBIEE benchmark results published so far are with the caching turned ON. This fact was not explicitly mentioned in some of the benchmark results white papers. Check the competitive Landscape for the pointers to different benchmark results published by different vendors.

• From our experiments with the OBIEE benchmark workload, it appears that a BI deployment with a single non-cluster BI node could reasonably scale well up to 7,500 active users on a T5440 server. To scale beyond 7,500 concurrent users, you might need another instance of BI. Of course, your mileage may vary.

• BI EE exhibited excellent horizontal scalability when multiple BI nodes were clustered using BI Cluster software. Four BI nodes in the Cluster were able to handle 28,000 concurrent users with minimal impact on the overall average transaction response times.

  It appeared as though we can simply add more BI nodes to the BI Cluster to cope with the increase in user base. However due to the limited hardware resources, we could not try running beyond 4 nodes in the BI Cluster. As of today, the theoritical limit for the number of BI nodes in a Cluster is 16.

• The underlying hardware must behave well in order for the application to scale and perform well -- so, credit goes to UltraSPARC T2 Plus powered Sun SPARC Enterprise T5440 server as well. In other words, it is fair to say the combination of (T5440 + OBIEE) performs and scales well on Solaris.

• A summary of the results with system-wide averages of CPU and memory utilization is shown below.

  #Vusers	Clustered	#BI Nodes	#CPU	#Core	RAM	CPU	Memory	Avg Trx Response Time	#Trx/sec
  7,500	No	1	1	8	32 GB	72.85%	18.11 GB	0.22 sec	155
  28,000	Yes	4	4	32	128 GB	75.04%	76.16 GB	0.25 sec	580

• Internal Solid State Drive (SSD) with ZFS file system showed significant I/O performance improvement over traditional disk for the BI catalog activity. In addition, ZFS helped get past the UFS limitation of 32,767 sub-directories in a BI catalog directory.

• The benchmark demonstrated that 64-bit BI EE platform is immune to the 4 GB virtual memory limitation of the 32-bit BI EE platform -- hence can potentially support even more users and have larger caches as long as the hardware resources are available.

  Solaris runs in 64-bit mode by default on SPARC platform. Consider running 64-bit BI EE on Solaris.

• 2,107 watts is the average power consumption when all the 28,000 concurrent users are in the steady state of the benchmark test. That is, in the case of similarly configured workloads, T5440 supports 13.2 users per watt of the power consumed; and supports 7,000 users per rack unit.

TOPOLOGY DIAGRAM:

A picture is worth a thousand words. The following topology diagram(s) says it all about the configuration.

1. Single Node BI Non-Cluster Configuration : 7,500 Concurrent Users

Even though the Solaris Container was shown in a cloud like graphical form, it has nothing to do with the "Cloud Computing". It is just a side effect of fancy drawing.

2. Four Node BI Cluster Configuration : 28,000 Concurrent Users

COMPETITIVE LANDSCAPE

Here is a quick summary of all the results that are published by different vendors. Feel free to draw your own conclusions. All this is public information. Check the corresponding benchmark reports by clicking on the URLs under the "#Users" column.

CAUTION

Although T5440 possesses a ton of great qualities, it might not be suitable for deploying workloads with heavy single-threaded dependencies. The T5440 is an excellent hardware platform for multi-threaded, and moderately single-threaded/multi-process workloads. When in doubt, it is a good idea to leverage Sun Microsystems' Try & Buy program to try the workloads on the T5440 server before making the final call.

Check the second part of this blog post for the best practices for configuring / deploying Oracle Business Intelligence on top of Solaris 10 running on Sun CMT hardware.

Related Blog Posts:

• Sun T5440 Oracle BI EE World Record Performance
• World Record Performance of Sun CMT Servers
• Why does 1.6 beat 4.7?
• Siebel 8.0 on Sun SPARC Enterprise T5440 - More Bang for the Buck!!

Posted at 04:35PM Aug 17, 2009 by Giri Mandalika in Benchmarks  |  Comments[1]

Oracle Business Intelligence on Sun : Few Best Practices

The following suggested best practices are applicable to all Oracle BI EE deployments on Sun hardware (CMT and M-class) running Solaris 10 or later. These recommendations are based on our observations from the 50,000 user benchmark on Sun SPARC Enterprise T5440. It is not the complete list, and your mileage may vary.

Ensure that the system's firmware is up-to-date.

Check the Sun System Firmware Release Hub for the latest firmware.

• Upgrade to the latest update release of Solaris 10.

• Solaris runs in 64-bit mode by default on SPARC platform. Consider running 64-bit BI EE on Solaris.

  64-bit BI EE platform is immune to the 4 GB virtual memory limitation of the 32-bit BI EE platform -- hence can potentially support even more users and have larger caches as long as the hardware resources are available.

• Enable 256M large pages on all nodes. By default, the latest update of Solaris 10 will use a maximum of 4M pages even when 256M pages are a good fit.
  256M pages can be enabled with the following /etc/system tunables.

  
  * 256M pages for the process heap
  set max_uheap_lpsize=0x10000000
  
  * 256M pages for ISM
  set mmu_ism_pagesize=0x10000000
  
  

• Increase the file descriptor limits by adding the following lines to /etc/system on all BI nodes.

  
  * file descriptor limits
  set rlim_fd_cur=65536
  set rlim_fd_max=65536
  
  

• On larger systems with more CPUs or CPU cores, try not to deploy Oracle BI EE in the global zone.

  In our benchmark testing, we have observed unpredictable and abnormal behavior of the BI server process (nqsserver) in the global zone under moderate loads. This behavior is clearly noticeable when there are more than 64 vcpus allocated to the global zone.

• If the BI presentation catalog is stored on a local file system, create a ZFS file system to hold the catalog.

  If there are more than 25,000 authorized users in a BI deployment, the default UFS file system may run into Too many links error when the Presentation Server tries to create more than 32,767 sub-directories (refer to LINK_MAX on Solaris)

• Store the Presentation Catalog on a disk with faster I/O such as a Solid State Drive (SSD). For uniform reads and writes across different disk drives [ and of course for better performance ], we recommend creating ZFS file system on top of a zpool with multiple SSDs.

  Here is an example that shows the ZFS file system creation steps for the BI Presentation Catalog.

  
  # zpool create -f BIshare c1t2d0s6 c1t3d0s0 c1t4d0s6 c1t5d0s6
  
  # zpool list
  NAME      SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
  BIshare   118G    97K   118G     0%  ONLINE  -
  
  # zfs create BIshare/WebCat
  
  # fstyp /dev/dsk/c1t2d0s6
  zfs
  
  # zpool status -v
    pool: BIshare
   state: ONLINE
   scrub: none requested
  config:
  
          NAME        STATE     READ WRITE CKSUM
          BIshare     ONLINE       0     0     0
            c1t2d0s6  ONLINE       0     0     0
            c1t3d0s0  ONLINE       0     0     0
            c1t4d0s6  ONLINE       0     0     0
            c1t5d0s6  ONLINE       0     0     0
  
  errors: No known data errors
  
  

  Observe the I/O activity on ZFS file system by running zpool iostat -v command.

• If the file system is mainly used for storing the Presentation Catalog, consider setting the ZFS record size to 8K. This is because of the relatively small size (8K or less) reads/writes from/into the BI Catalog.

  eg.,

  
          # zfs set recordsize=8K BIshare/WebCat
  
  

  In the case of database, you may have to set the ZFS record size to the database block size.

• Even though disabling ZFS Intent Log (ZIL) may improve the performance of synchronous write operations, it is not a recommended practice to disable ZIL. Doing so may compromise the data integrity.

  Disabling the ZIL on an NFS Server can lead to client side corruption.

• When running CPU intensive workloads, consider disabling the ZFS' metadata compression to provide more CPU cycles to the application.

  Starting with Solaris 10 11/06, metadata compression can be disabled and enabled dynamically as shown below.

  To disable the metadata compression:

  
          # echo zfs_mdcomp_disable/W0t1 | mdb -kw
  
  

  To enable the metadata compression:

  
          # echo zfs_mdcomp_disable/W0t0 | mdb -kw
  
  

  To permanently disable the metadata compression, set the following /etc/system tunable.

  
          set zfs:zfs_mdcomp_disable=1
  
  

One of the requirements of OBIEE is that the BI Presentation Catalog must be shared across different BI nodes in the BI Cluster. (There will be only one copy of the presentation catalog). Unless the catalog has been replicated on different nodes, there is no other choice but to share it across different nodes. One way to do this is to create an NFS share with the top level directory of the catalog, and then to mount it over NFS at the BI nodes.

• Version 4 is the default NFS version on Solaris 10. However it appears that as of this writing, NFS v4 is not as mature as v3. So we recommend experimenting with both versions to see which one fits well to the needs of the BI deployment.

  To enable NFS v3 on both server and the client, edit /etc/default/nfs and make the changes as shown below.

  NFS Server

  NFS_SERVER_VERSMIN=3
  NFS_SERVER_VERSMAX=3

  NFS Client

  NFS_CLIENT_VERSMIN=3
  NFS_CLIENT_VERSMAX=3

• Experiment with the following NFS tunables.

  NFS Server

  
  NFSD_SERVERS=<desired_number> <-- on CMT systems with large number of hardware threads you can go as high as 512
  NFS_SERVER_DELEGATION=[ON|OFF] <-- ON is the default. Experiment with OFF
  NFSMAPID_DOMAIN=<network_domain_where_BI_was_deployed>
  
  

  NFS Client

  NFSMAPID_DOMAIN=<network_domain_where_BI_was_deployed>

• Monitor the DNLC hit rate and tune the directory name look-up cache (DNLC).

  To monitor the DNLC hit rate, run "vmstat -s | grep cache" command. It is ideal to see a hit rate of 95% or above.

  Add the following tunable parameter to /etc/system on NFS server with a desired value for the DNLC cache.

  
          set ncsize=<desired_number>
  
  

• Mounting NFS Share

  Mount the NFS share that contains the Presentation Services Catalog on all the NFS clients (BI nodes in this context) using the following mount options:

  
          rw, forcedirectio, nocto
  
  

• Ensure that all the BI components in the cluster are configured in a many-to-many fashion

• For proper load balancing, configure all BI nodes to be identical in the BI Cluster

• When planning to add an identically configured new node to the BI Cluster, simply clone an existing well-configured BI node running in a non-global zone.

  Cloning a BI node running in a dedicated zone results in an exact copy of the BI node being cloned. This approach is simple, less error prone and eliminates the need to configure the newly added node from scratch.

• Increase the file descriptors limit. Edit SAROOTDIR/setup/systunesrv.sh to increase the value from 1024 to any other value of your choice. In addition you must increase the shell limit using the ulimit -n command

  eg.,

  
  	ulimit -n 2048
  
  

• Configure 256M large pages for the JVM heap of Chart server and OC4J web server (this recommendation is equally applicable to other web servers such as WebLogic or Sun Java system Web Server). Also use parallel GC, and restrict the number of parallel GC threads to 1/8th of the number of virtual cpus.

  eg.,

  
  	-XX:LargePageSizeInBytes=256M -XX:+UseParallelGC -XX:ParallelGCThreads=8
  
  

• The Oracle BI Presentation Server keeps the access information of all the users in the Web Catalog. When there are large number of unique BI users, it can take a significant amount of time to look up a user if all the users reside in a single directory. To avoid this, hash the user directories. It can be achieved by having the following entry in SADATADIR/web/config/instanceconfig.xml

  eg.,

  
  	<Catalog>
  		<HashUserHomeDirectories>2</HashUserHomeDirectories>
  	</Catalog>
  
  

  HashUserHomeDirectories specifies the number of characters to use to hash user names into sub directories. When this element is turned on, for example, the default name for user Steve's home directory would become /users/st/steve.

• BI Server and BI Presentation Server processes create many temporary files while rendering reports and dashboards for a user. This can result in significant I/O activity on the system. The I/O waits can be minimized by pointing the temporary directories to a memory resident file system such as /tmp on Solaris OS. To achieve this, add the following line to the instanceconfig.xml configuration file.

  eg.,

  
  	<TempDir>/tmp/OracleBISAW</TempDir>
  
  

  Similarly the Temporary directory (SATEMPDIR) can be pointed to a memory resident file system such as /tmp to minimize the I/O waits.

• Consider tuning the value of CacheMaxEntries in instanceconfig.xml. A value of 20,000 was used in the 50,000 user OBIEE benchmark on T5440 servers. Be aware that the Presentation Services process (sawserver64) consumes more virtual memory when this parameter is set to a high value.

  eg.,

  
  	<CacheMaxEntries>20000</CacheMaxEntries>
  
  

• If the presentation services log contains errors such as "The queue for the thread pool AsyncLogon is at it's maximum capacity of 50 jobs.", consider increasing the Presentation Services' asynchronous job queue. 50 is the default value.

  The following example increases the job queue size to 200.

  
  	<ThreadPoolDefaults>
  		<AsyncLogon>
  			<MaxQueue>200</MaxQueue>
  		</AsyncLogon>
  	</ThreadPoolDefaults>
  
  

• Increase the query cache expiry time especially when the BI deployment is supposed to handle large number of concurrent users. The default is 60 minutes. However under very high loads, a cache entry may be removed before one hour if many queries are being run. Hence it is necessary to tune the parameter CacheMaxExpireMinutes in Presentation Services' instanceconfig.xml.

  The following example increases the query cache expiry time to 3 hours.

  
  	<CacheMaxExpireMinutes>180</CacheMaxExpireMinutes>
  
  

• Consider increasing the Presentation Services' cache timeout values to keep the cached data intact for longer periods.

  The following example increases the cache timeout values to 5 hours in instanceconfig.xml configuration file.

  
  	<AccountIndexRefreshSecs>18000</AccountIndexRefreshSecs>
  	<AccountCacheTimeoutSecs>18000</AccountCacheTimeoutSecs>
  	<CacheTimeoutSecs>18000</CacheTimeoutSecs>
  	<CacheCleanupSecs>18000</CacheCleanupSecs>
  	<PrivilegeCacheTimeoutSecs>18000</PrivilegeCacheTimeoutSecs>
  
  

• Enable caching at the BI server and control/tune the cache expiry time for each of the table based on your organizations' needs.

• Unless the repository needs to be edited online frequently, consider setting up the "read only" mode for the repository. It may ease lock contention up to some extent.

• Increase the session limit and the number of requests per session limit especially when the BI deployment is expected to handle large number of concurrent users. Also increase the number of BI server threads.

  The following configuration was used in 50,000 user OBIEE benchmark on T5440 servers.

  
  (Source configuration file: NQSConfig,.INI)
  
  [ CACHE ]
  ENABLE = YES;
  DATA_STORAGE_PATHS = "/export/oracle/OracleBIData/cache" 500 MB;
  MAX_ROWS_PER_CACHE_ENTRY = 0;
  MAX_CACHE_ENTRY_SIZE = 10 MB;
  MAX_CACHE_ENTRIES = 5000;
  POPULATE_AGGREGATE_ROLLUP_HITS = NO;
  USE_ADVANCED_HIT_DETECTION = NO;
  
  // Cluster-aware cache
  GLOBAL_CACHE_STORAGE_PATH = "/export/oracle/OracleBIsharedRepository/GlobalCacheDirectory" 2048 MB;
  MAX_GLOBAL_CACHE_ENTRIES = 10000;
  CACHE_POLL_SECONDS = 300;
  CLUSTER_AWARE_CACHE_LOGGING = NO;
  
  [ SERVER ]
  READ_ONLY_MODE = YES;
  MAX_SESSION_LIMIT = 20000 ;
  MAX_REQUEST_PER_SESSION_LIMIT = 1500 ;
  SERVER_THREAD_RANGE = 512-2048;
  SERVER_THREAD_STACK_SIZE = 0;
  DB_GATEWAY_THREAD_RANGE = 512-512;
  
  #SERVER_HOSTNAME_OR_IP_ADDRESSES = "ALLNICS";
  CLUSTER_PARTICIPANT = YES;
  
  

• Sun achieves the Magic Number 50,000 on T5440 with Oracle Business Intelligence EE 10.1.3.4
• T5440 Rocks [again] with Oracle Business Intelligence Enterprise Edition Workload
• Siebel on Sun CMT hardware : Best Practices

Posted at 04:35PM Aug 17, 2009 by Giri Mandalika in Performance  |  Comments[0]

Solaris 10: Zone Creation for Dummies

About Zones

In its simple form, a zone is a virtual operating system environment created within a single instance of the Solaris operating system. Efficient resource utilization is the main goal of this technology.

Solaris 10's zone partitioning technology can be used to create local zones that behave like virtual servers. All local zones are controlled from the system's global zone. Processes running in a zone are completely isolated from the rest of the system. This isolation prevents processes that are running in one zone from monitoring or affecting processes that are running in other zones. Note that processes running in a local zone can be monitored from global zone; but the processes running in a global zone or even in another local zone cannot be monitored from a local zone.

As of now, the upper limit for the number of zones that can be created/run on a system is 8192; of course, depending on the resource availability, a single system may or may not run all the configured zones effectively.

Global Zone

When we install Solaris 10, a global zone gets installed automatically; and the core operating system runs under global zone. To list all the configured zones, we can use zoneadm command:

 % zoneadm list -v
  ID NAME             STATUS         PATH
   0 global           running        /

Global zone is the only one:

• bootable from the system hardware
• to be used for system-wide administrative control, such as physical devices, routing, or dynamic reconfiguration (DR). ie., global zone is the only zone that is aware of all devices and all file systems
• from which a non-global zone can be configured, installed, managed, or uninstalled. ie., global zone is the only zone that is aware of the existence of non-global (local) zones and their configurations. It is not possible to create local zones, within a local zone

Steps to create a Local Zone

Prerequisites:

• Plenty of disk space to hold the newly installed zone. It needs at least 2G space to copy the essential files to the local zone, and of course the disk space needed by the application(s) you are planning to run, in this zone; and
• A dedicated IP for network connectivity

Basic Zone creation steps with examples:

1. Check the disk space & network configuration

   
    % df -h /
    Filesystem             size   used  avail capacity  Mounted on
    /dev/dsk/c1t1d0s0       29G    22G   7.1G    76%    /
   
    % ifconfig -a
    lo0: flags=2001000849 mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000
    eri0: flags=1000843 mtu 1500 index 2
            inet 192.168.74.217 netmask fffffe00 broadcast 192.168.75.255
   
   

2. Since there is more than 5G free space, I've decided to install a local zone under /zones.

   
    % mkdir /zones
   
   

3. Next step is to define/create the zone root. This is the path to zone's root directory that is relative to the global zone's root directory. Zone root must be owned by root user with the mode 700. This will be used in setting the zonepath property, during the zone creation process

   
    % cd /zones
    % mkdir appserver
    % chmod 700 appserver
   
    % ls -l
    total 2
    drwx------   2 root     root         512 Feb 17 12:46 appserver
   
   

4. Create & configure a new 'sparse root' local zone, with root privileges

   
    % zonecfg -z appserv
    appserv: No such zone configured
    Use 'create' to begin configuring a new zone.
    zonecfg:appserv> create
    zonecfg:appserv> set zonepath=/zones/appserver
    zonecfg:appserv> set autoboot=true
    zonecfg:appserv> add net
    zonecfg:appserv:net> set physical=eri0
    zonecfg:appserv:net> set address=192.168.175.126
    zonecfg:appserv:net> end
    zonecfg:appserv> add fs
    zonecfg:appserv:fs> set dir=/repo2
    zonecfg:appserv:fs> set special=/dev/dsk/c2t40d1s6
    zonecfg:appserv:fs> set raw=/dev/rdsk/c2t40d1s6
    zonecfg:appserv:fs> set type=ufs
    zonecfg:appserv:fs> set options noforcedirectio
    zonecfg:appserv:fs> end
    zonecfg:appserv> add inherit-pkg-dir
    zonecfg:appserv:inherit-pkg-dir> set dir=/opt/csw
    zonecfg:appserv:inherit-pkg-dir> end
    zonecfg:appserv> info
    zonepath: /zones/appserver
    autoboot: true
    pool:
    inherit-pkg-dir:
            dir: /lib
    inherit-pkg-dir:
            dir: /platform
    inherit-pkg-dir:
            dir: /sbin
    inherit-pkg-dir:
            dir: /usr
    inherit-pkg-dir:
            dir: /opt/csw
    net:
            address: 192.168.175.126
            physical: eri0
    zonecfg:appserv> verify
    zonecfg:appserv> commit
    zonecfg:appserv> exit
   
   

   Sparse Root Zone Vs Whole Root Zone(Updated 05/07/2008)

   In a Sparse Root Zone, the directories /usr, /sbin, /lib and /platform will be mounted as loopback file systems. That is, although all those directories appear as normal directories under the sparse root zone, they will be mounted as read-only file systems. Any change to those directories in the global zone can be seen from the sparse root zone.

   However if you need the ability to write into any of those directories listed above, you may need to configure a Whole Root Zone. For example, softwares like ClearCase need write permissions to /usr directory. In that case configuring a Whole Root Zone is the way to go. The steps for creating and configuring a new 'Whole Root' local zone are as follows:

   
    % zonecfg -z appserv
    appserv: No such zone configured
    Use 'create' to begin configuring a new zone.
    zonecfg:appserv> create
    zonecfg:appserv> set zonepath=/zones/appserver
    zonecfg:appserv> set autoboot=true
    zonecfg:appserv> add net
    zonecfg:appserv:net> set physical=eri0
    zonecfg:appserv:net> set address=192.168.175.126
    zonecfg:appserv:net> end
    zonecfg:appserv> add inherit-pkg-dir
    zonecfg:appserv:inherit-pkg-dir> set dir=/opt/csw
    zonecfg:appserv:inherit-pkg-dir> end
    zonecfg:appserv> remove inherit-pkg-dir dir=/usr
    zonecfg:appserv> remove inherit-pkg-dir dir=/sbin
    zonecfg:appserv> remove inherit-pkg-dir dir=/lib
    zonecfg:appserv> remove inherit-pkg-dir dir=/platform
    zonecfg:appserv> info
    zonepath: /zones/appserver
    autoboot: true
    pool:
    inherit-pkg-dir:
            dir: /opt/csw
    net:
            address: 192.168.175.126
            physical: eri0
    zonecfg:appserv> verify
    zonecfg:appserv> commit
    zonecfg:appserv> exit
   
   

   Brief explanation of the properties that I added:

   * zonepath=/zones/appserver

   Local zone's root directory, relative to global zone's root directory. ie., local zone will have all the bin, lib, usr, dev, net, etc, var, opt etc., directories physically under /zones/appserver directory

   * autoboot=true

   boot this zone automatically when the global zone is booted

   * physical=eri0

   eri0 card is used for the physical interface

   * address=192.168.175.126

   192.168.175.126 is the IP address. It must have all necessary DNS entries

   [Added 08/25/08] The whole add fs section adds the file system to the zone. In this example, the file system that is being exported to the zone is an existing UFS file system.

   * set dir=/repo2

   /repo2 is the mount point in the local zone

   * set special=/dev/dsk/c2t40d1s6 set raw=/dev/rdsk/c2t40d1s6

   Grant access to the block (/dev/dsk/c2t40d1s6) and raw (/dev/rdsk/c2t40d1s6) devices so the file system can be mounted in the non-global zone. Make sure the block device is not mounted anywhere right before installing the non-global zone. Otherwise, the zone installation may fail with ERROR: file system check </usr/lib/fs/ufs/fsck> of </dev/rdsk/c2t40d1s6> failed: exit status <33>: run fsck manually. In that case, unmount the file system that is being exported, uninstall the partially installed zone (zoneadm -z <zone> uninstall) then install the zone from the scratch (no need to re-configure the zone, just do a re-install).

   * set type=ufs

   The file system is of type UFS

   * set options noforcedirectio

   Mount the file system with the option noforcedirectio[/Added 08/25/08]

   * dir=/opt/csw

   read-only path, will be lofs'd (loop back mounted) from global zone. Note: it works for sparse root zone only -- whole root zone cannot have any shared file systems

   zonecfg commands verify and commit, verifies and commits the zone configuration for the zone, respectively. Note that it is not necessary to commit the zone configuration; it will be done automatically when we exit from zonecfg tool. info displays information about the current configuration

5. Check the state of the newly created/configured zone

   
    % zoneadm list -cv
      ID NAME             STATUS         PATH
       0 global           running        /
       - appserv          configured     /zones/appserver
   
   

6. Next step is to install the configured zone. It takes a while to install the necessary packages

   
    % zoneadm -z appserv install
    /zones must not be group writable.
    could not verify zonepath /zones/appserver because of the above errors.
    zoneadm: zone appserv failed to verify
   
    % ls -ld /zones
    drwxrwxr-x   3 root     root         512 Feb 17 12:46 /zones
   
   

   Since /zones must not be group writable, let's change the mode to 700.

   
    % chmod 700 /zones
   
    % ls -ld /zones
    drwx------   3 root     root         512 Feb 17 12:46 /zones
   
    % zoneadm -z appserv install
    Preparing to install zone .
    Creating list of files to copy from the global zone.
    Copying <2658> files to the zone.
    Initializing zone product registry.
    Determining zone package initialization order.
    Preparing to initialize <1128> packages on the zone.
    Initialized <1128> packages on zone.
    Zone  is initialized.
    Installation of these packages generated errors: 
    Installation of <2> packages was skipped.
    Installation of these packages generated warnings: <CSWbdb3 CSWtcpwrap 
     CSWreadline CSWlibnet CSWlibpcap CSWjpeg CSWzlib  CSWcommon CSWpkgget SMCethr CSWxpm 
     SMClsof SMClibgcc SMCossld OpenSSH SMCtar SUNWj3dmx CSWexpat CSWftype2 CSWfconfig 
     CSWiconv  CSWggettext CSWlibatk CSWpango CSWpng CSWtiff CSWgtk2 CSWpcre CSWlibmm 
     CSWgsed CSWlibtool CSWncurses CSWunixodbc CSWoldap  CSWt1lib CSWlibxml2 CSWbzip2 
     CSWlibidn CSWphp>
    The file  contains a log of the zone installation.
   
   

7. Verify the state of the appserv zone, one more time

   
    % zoneadm list -cv
      ID NAME             STATUS         PATH
       0 global           running        /
       - appserv          installed      /zones/appserver
   
   

8. Boot up the appserv zone. Let's note down the ifconfig output to see how it changes after the local zone boots up. Also observe that there is no answer from the server yet, since it is not up

   
    % ping 192.168.175.126
    no answer from 192.168.175.126
   
    % ifconfig -a
    lo0: flags=2001000849 mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000
    eri0: flags=1000843 mtu 1500 index 2
            inet 192.168.74.217 netmask fffffe00 broadcast 192.168.75.255
            ether 0:3:ba:2d:0:84
   
    % zoneadm -z appserv boot
    zoneadm: zone 'appserv': WARNING: eri0:1: no matching subnet found in netmasks(4) for 192.168.175.126; 
    using default of  255.255.0.0.
   
    % zoneadm list -cv
      ID NAME             STATUS         PATH
       0 global           running        /
       1 appserv          running        /zones/appserver
   
    % ping 192.168.175.126
    192.168.175.126 is alive
   
    % ifconfig -a
    lo0: flags=2001000849 mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000
    lo0:1: flags=2001000849 mtu 8232 index 1
            zone appserv
            inet 127.0.0.1 netmask ff000000
    eri0: flags=1000843 mtu 1500 index 2
            inet 192.168.74.217 netmask fffffe00 broadcast 192.168.75.255
            ether 0:3:ba:2d:0:84
    eri0:1: flags=1000843 mtu 1500 index 2
            zone appserv
            inet 192.168.175.126 netmask ffff0000 broadcast 192.168.255.255
   
   

   Observe that the zone appserv has it's own virtual instance of lo0, the system's loopback interface and the zone's IP address is also being served by the eri0 network interface

9. Login to the Zone {console} and performing the internal zone configuration. zlogin utility can be used to enter a zone. The first time we log in to the console, we get a chance to answer a series of questions for the desired zone configuraton. -C option of zlogin can be used to log in to the Zone console.

   
    % zlogin -C -e [ appserv
    [Connected to zone 'appserv' console]
   
    Select a Language
   
      0. English
      1. es
      2. fr
   
    Please make a choice (0 - 2), or press h or ? for help: 0
   
    Select a Locale
   
      0. English (C - 7-bit ASCII)
      1. Canada (English) (UTF-8)
      2. Canada-English (ISO8859-1)
      3. U.S.A. (UTF-8)
      4. U.S.A. (en_US.ISO8859-1)
      5. U.S.A. (en_US.ISO8859-15)
      6. Go Back to Previous Screen
   
    Please make a choice (0 - 6), or press h or ? for help: 0
   
    ...
   
     Enter the host name which identifies this system on the network.  The name
      must be unique within your domain; creating a duplicate host name will cause
      problems on the network after you install Solaris.
   
      A host name must have at least one character; it can contain letters,
      digits, and minus signs (-).
   
        Host name for eri0:1 appserv v440appserv
   
    ...
    ...
   
    System identification is completed. 
    ...
    
    rebooting system due to change(s) in /etc/default/init
    
    [NOTICE: Zone rebooting]
   
    SunOS Release 5.11 Version snv_23 64-bit
    Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
    Use is subject to license terms.
    Hostname: v440appserv
   
    v440appserv console login: root
    Password:
    Feb 17 15:15:30 v440appserv login: ROOT LOGIN /dev/console
    Sun Microsystems Inc.   SunOS 5.11      snv_23  October 2007
   
    %
   
   

That is all there is in the creation of a local zone. Now simply login to the newly created zone, just like connecting to any other system in the network.

[New 08/27/2008] Mounting file systems in a non-global zone

Sometimes it might be necessary to export file systems or create new file systems when the zone is already running. This section's focus is on exporting block devices and the raw devices in such situations i.e., when the local zone is already configured.

Exporting the Raw Device(s) to a non-global zone

If the file system does not exist on the device, raw devices can be exported as they are, so the file system can be created inside the non-global zone using the normal newfs command.

The following example shows how to export the raw device to a non-global zone when the zone is already configured.

# zonecfg -z appserv
zonecfg:appserv> add device
zonecfg:appserv:device> set match=/dev/rdsk/c5t0d0s6
zonecfg:appserv:device> end
zonecfg:appserv> verify
zonecfg:appserv> commit
zonecfg:appserv> exit

In this example /dev/rdsk/c5t0d0s6 is being exported.

After the zonecfg step, reboot the non-global zone to make the raw device visible inside the non-global zone. After the reboot, check the existence of the raw device.

# hostname
v440appserv

# ls -l /dev/rdsk/c5t0d0s6
crw-r-----   1 root     sys      118, 126 Aug 27 14:33 /dev/rdsk/c5t0d0s6

Now that the raw device is accessible within the non-global zone, we can use the regular Solaris commands to create any file system like UFS.

# newfs -v c5t0d0s6
newfs: construct a new file system /dev/rdsk/c5t0d0s6: (y/n)? y
mkfs -F ufs /dev/rdsk/c5t0d0s6 1140260864 -1 -1 8192 1024 251 1 120 8192 t 0 -1 8 128 n
Warning: 4096 sector(s) in last cylinder unallocated
/dev/rdsk/c5t0d0s6: 1140260864 sectors in 185590 cylinders of 48 tracks, 128 sectors
 556768.0MB in 11600 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
...............................................................................
...............................................................................
.........................................................................
super-block backups for last 10 cylinder groups at:
 1139344160, 1139442592, 1139541024, 1139639456, 1139737888, 1139836320,
 1139934752, 1140033184, 1140131616, 1140230048

Exporting the Block Device(s) to a non-global zone

If the file system exists on the device, block devices can be exported as they are, so the file system can be mounted inside the non-global zone using the normal Solaris command, mount.

The following example shows how to export the block device to a non-global zone when the zone is already configured.

# zonecfg -z appserv
zonecfg:appserv> add device
zonecfg:appserv:device> set match=/dev/dsk/c5t0d0s6
zonecfg:appserv:device> end
zonecfg:appserv> verify
zonecfg:appserv> commit
zonecfg:appserv> exit

In this example /dev/dsk/c5t0d0s6 is being exported.

After the zonecfg step, reboot the non-global zone to make the block device visible inside the non-global zone. After the reboot, check the existence of the block device; and mount the file system within the non-global zone.

# hostname
v440appserv

# ls -l /dev/dsk/c5t0d0s6
brw-r-----   1 root     sys      118, 126 Aug 27 14:40 /dev/dsk/c5t0d0s6

# fstyp /dev/dsk/c5t0d0s6
ufs

# mount /dev/dsk/c5t0d0s6 /mnt

# df -h /mnt
Filesystem             size   used  avail capacity  Mounted on
/dev/dsk/c5t0d0s6      535G    64M   530G     1%    /mnt

Mounting a file system from the global zone into the non-global zone

Sometimes it is desirable to have the flexibility of mounting a file system in the global zone or non-global zone on-demand. In such situations, rather than exporting the file systems or block devices into the non-global zone, create the file system in the global zone and mount the file system directly from the global zone into the non-global zone. Make sure to unmount that file system in the global zone if mounted, before attempting to mount it in the non-global zone.

In the non-global zone:

# mkdir /repo1

In the global zone:

# df -h /repo1
/dev/dsk/c2t40d0s6     134G    64M   133G     1%    /repo1

# umount /repo1

# ls -ld /zones/appserv/root/repo1
drwxr-xr-x   2 root     root         512 Aug 27 14:45 /zones/appserv/root/repo1

# mount /dev/dsk/c2t40d0s6 /zones/appserv/root/repo1

Now go back to the non-global zone and check the mounted file systems.

# hostname
v440appserv

# df -h /repo1
Filesystem             size   used  avail capacity  Mounted on
/repo1                 134G    64M   133G     1%    /repo1

# umount /zones/appserv/root/repo1

Removing the file system from the non-global zone

Earlier in the zone creation step, the block device /dev/dsk/c2t40d1s6 was exported and mounted on the mount point /repo2 inside the non-global zone. To remove the file system completely from the non-global zone, run the following in the global zone.

# zonecfg -z appserv
zonecfg:appserv> remove fs dir=/repo2
zonecfg:appserv> verify
zonecfg:appserv> commit
zonecfg:appserv> exit

Reboot the non-global zone for this setting to take effect.

Shutting down and booting up the local zones (Updated 01/15/2008)

1. To bring down the local zone:

   
    % zlogin appserv shutdown -i 0
   
   

2. To boot up the local zone:

   
    % zoneadm -z appserv boot
   
   

Just for the sake of completeness, the following steps show how to remove a local zone.

Steps to delete a Local Zone

1. Shutdown the local zone

   
    % zoneadm -z appserv halt
   
    % zoneadm list -cv
      ID NAME             STATUS         PATH
       0 global           running        /
       - appserv          installed      /zones/appserver
   
   

2. Uninstall the local zone -- remove the root file system

   
    % zoneadm -z appserv uninstall
    Are you sure you want to uninstall zone appserv (y/[n])? y
   
     zoneadm list -cv
      ID NAME             STATUS         PATH
       0 global           running        /
       - appserv          configured     /zones/appserver
   
   

3. Delete the configured local zone

   
    % zonecfg -z appserv delete
    Are you sure you want to delete zone appserv (y/[n])? y
   
     zoneadm list -cv
      ID NAME             STATUS         PATH
       0 global           running        /
   
   

[New: 07/14/2009]

Cloning a Non-Global Zone

The following instructions are for cloning a non-global zone on the same system. The example shown below clones the siebeldb zone. After the cloning process, a brand new zone oraclebi emerges as a replica of siebeldb zone.

# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - siebeldb         installed  /zones/dbserver                native   excl

1. Export the configuration of the zone that you want to clone/copy

   
   # zonecfg -z siebeldb export > /tmp/siebeldb.config.cfg
   
   

2. Change the configuration of the new zone that differ from the existing one -- for example, IP address, data set names, network interface etc. To make these changes, edit /tmp/siebeldb.config.cfg

3. Create the zone root directory for the new zone being created

   
   # mkdir /zones3/oraclebi
   # chmod 700 /zones3/oraclebi
   # ls -ld /zones3/oraclebi
   drwx------   2 root     root         512 Mar 12 15:41 /zones3/oraclebi
   
   

4. Create a new (empty, non-configured) zone in the usual manner with the edited configuration file as an input

   
   # zonecfg -z oraclebi -f /tmp/siebeldb.config.cfg
   
   #  zoneadm list -cv
     ID NAME             STATUS     PATH                           BRAND    IP    
      0 global           running    /                              native   shared
      - siebeldb         installed  /zones/dbserver                native   excl   
      - oraclebi         configured /zones3/oraclebi               native   excl
   
   

5. Ensure that the zone you intend to clone/copy is not running

   
   # zoneadm -z siebeldb halt
   
   

6. Clone the existing zone

   
   # zoneadm -z oraclebi clone siebeldb
   Cloning zonepath /zones/dbserver...
   
   

   This step takes at least 5 minutes to clone the whole zone. Larger zones may take longer to complete the cloning process.

7. Boot the newly created zone

   
   # zoneadm -z oraclebi boot
   
   

   Bring up the halted zone (the source zone) as well, if wish.

8. Login to the console of the new zone to configure IP, networking, etc., and you are done.

   
   # zlogin -C oraclebi
   
   

[New: 07/15/2009]

Migrating a Non-Global Zone from One Host to Another

Keywords: Solaris, Non-Global Zone, Migration, Attach, Detach

The following instructions demonstrate how to migrate the non-global zone, orabi to another server with examples.

# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   4 siebeldb         running    /zones/dbserver                native   excl  
   - orabi            installed  /zones3/orabi                  native   shared

1. Halt the zone to be migrated, if running

   
   # zoneadm -z orabi halt
   
   

2. Detach the zone. Once detached, it will be in the configured state

   
   # zoneadm -z orabi detach
   
   # zoneadm list -cv
     ID NAME             STATUS     PATH                           BRAND    IP    
      0 global           running    /                              native   shared
      4 siebeldb         running    /zones/dbserver                native   excl  
      - orabi            configured /zones3/orabi                  native   shared
   
   

3. Move the zonepath for the zone to be migrated from the old host to the new host.

   Do the following on the old host:

   
   # cd /zones3
   # tar -Ecf orabi.tar orabi
   # compress orabi.tar
   
   # sftp newhost
   Connecting to newhost...
   sftp> cd /zones3
   sftp> put orabi.tar.Z
   Uploading orabi.tar.Z to /zones3/orabi.tar.Z
   sftp> quit
   
   

   On the newhost:

   
   # cd /zones3
   # uncompress orabi.tar.Z
   # tar xf orabi.tar
   
   

4. On the new host, configure the zone.

   Create the equivalent zone orabi on the new host -- use the zonecfg command with the -a option and the zonepath on the new host. Make any required adjustments to the configuration and commit the configuration.

   
   # zonecfg -z orabi
   orabi: No such zone configured
   Use 'create' to begin configuring a new zone.
   zonecfg:orabi> create -a /zones3/orabi
   zonecfg:orabi> info
   zonename: orabi
   zonepath: /zones3/orabi
   brand: native
   autoboot: false
   bootargs: 
   pool: 
   limitpriv: all,!sys_suser_compat,!sys_res_config,!sys_net_config,!sys_linkdir,!sys_devices,!sys_config,!proc_zone,!dtrace_kernel,!sys_ip_config
   scheduling-class: 
   ip-type: shared
   inherit-pkg-dir:
    dir: /lib
   inherit-pkg-dir:
    dir: /platform
   inherit-pkg-dir:
    dir: /sbin
   inherit-pkg-dir:
    dir: /usr
   net:
    address: IPaddress
    physical: nxge1
    defrouter not specified
   zonecfg:orabi> set capped-memory
   zonecfg:orabi:capped-memory> set physical=8G
   zonecfg:orabi:capped-memory> end
   zonecfg:orabi> commit
   zonecfg:orabi> exit
   
   

5. Attach the zone on the new host with a validation check and update the zone to match a host running later versions of the dependent packages

   
   # ls -ld /zones3
   drwxrwxrwx   5 root     root         512 Jul 15 12:30 /zones3
   # chmod g-w,o-w /zones3
   # ls -ld /zones3
   drwxr-xr-x   5 root     root         512 Jul 15 12:30 /zones3
   
   # zoneadm -z orabi attach -u
   Getting the list of files to remove
   Removing 1740 files
   Remove 607 of 607 packages
   Installing 1878 files
   Add 627 of 627 packages
   Updating editable files
   The file  within the zone contains a log of the zone update.
   
   # zoneadm list -cv
     ID NAME             STATUS     PATH                           BRAND    IP    
      0 global           running    /                              native   shared
      - orabi            installed  /zones3/orabi                  native   shared
   
   

   Note:

   It is possible to force the attach operation without performing the validation. You can do so with the help of -F option

   
   # zoneadm -z orabi attach -F
   
   

   Be careful when using this option because it could lead to an incorrect configuration; and an incorrect configuration could result in undefined behavior

[New: 07/19/2009]

Tip: How to find out whether connected to the primary OS instance or the virtual instance?

If the command zonename returns global, then you are connected to the OS instance that was booted from the physical hardware. If you see any string other than global, you might have connected to the virtual OS instance.

Alternatively try running prstat -Z or zoneadm list -cv commands. If you see exactly one non-zero Zone ID, it is an indication that you are connected to a non-global zone.

Suggested reading:

• System Administration Guide: Solaris Containers-Resource Management and Solaris Zones
• Zones and Containers FAQ at opensolaris.org
• Zones : Unofficial FAQ

Posted at 09:39PM Jul 19, 2009 by Giri Mandalika in Solaris  |  Comments[0]

Oracle Business Intelligence : Workaround / Solution to "[46036] Internal Assertion" Error

Symptom:

When checking in changes to Oracle BI repository (RPD), Admintool fails with an error message:

    [46036] Internal Assertion: Condition FALSE, file server/Utility/Generic/NQThreads/SUGThread.cpp, line 515

Solution / Workaround:

Edit <BI_HOME>/server/Config/NQSConfig.INI configuration file to increase the value of SERVER_THREAD_STACK_SIZE parameter. Replace the line SERVER_THREAD_STACK_SIZE = 0; with SERVER_THREAD_STACK_SIZE = 512 KB; and restart the Analytics server (SAS)

Posted at 08:49PM Jul 11, 2009 by Giri Mandalika in Enterprise  |  Comments[0]