Netezza system Logs

March 5, 2014, 5:12 pm

≫ Next: Sequence – Issue with Netezza restart?

Some basic info about how and where Netezza system logs are stored, recycled and deleted.

- All system level logs are written under /nz/kit/log in respective directories
- Log files can have name like <pid>.<yyyy-mm-dd> depending on the log/component
- Each log file can have atleast 1 day data upto max of 7 days
- Each log file will have timestamp, severity and message
- Except postgress log all other log files are archived every day and 30 days log files are kept by system
- Postgress logs are moved to archive when it reached 1 GB size and max of 28 days archived postgress log files are kept
- Default retention of log files can be changed bu tfor that Neteza support help is needed

Sequence – Issue with Netezza restart?

March 18, 2014, 4:07 am

≫ Next: How to find Netezza model type?

≪ Previous: Netezza system Logs

In Netezza, sequence can be declared as 8-, 16-, 32-, or 64-bit integers and the cache size is a function of the number of distinct values in one complete cycle of the sequence (so it depends on the declared minvalue, maxvalue, and increment of the sequence).

↧

How to find Netezza model type?

April 8, 2014, 9:17 am

≫ Next: nzvacuumcat in Netezza

≪ Previous: Sequence – Issue with Netezza restart?

To find if Netezza system is a Mustang box, TwinFin or Striper by connecting to the server using putty:

1) Run Netezza provided support script nz_get_model

eg. Below was run on Mustang 10100 model
/export/home/nz->nz_get_model
10100SL

↧

nzvacuumcat in Netezza

May 7, 2014, 9:28 am

≫ Next: Row set limit in Netezza

≪ Previous: How to find Netezza model type?

nzvacuumcat in Netezza is:

- Netezza background process which strats at Netezza boot time.All background processes are started by startupsvr background process
- During, Netezza boot time it invokes VACUUM command to groom system tables for faster table scans by removing deleted records and shrinking the system tables.
- When Netezza is running, it checks for database system table growth above 120 KB (checks every 60 secs) and invokes system table vacuum if it grows above 128 KB.
- VACUUM command takes exclusive locks on all system catalog tables before vacuuming the system tables.
- nzvacuumcat will shrink the database size only when Vacuum command runs succesfully.
- If it is not able to aquire locks, system will write ‘Could not acquire lock for lazy vacuum’ message in pg.log and will try again after some time.

Row set limit in Netezza

May 19, 2014, 9:30 am

≫ Next: Nzstop vs Nzsystem stop

≪ Previous: nzvacuumcat in Netezza

Some info about row set limit in Netezza:

- We can set the maximum number of rows retrieved by a query at user level or group level.
- Rowset limit can be set upto 1 billion rows or set it to 0 for unlimited.
- Rowset limit only applied to user table and views. Queries to system table and view are not limied by this setting.
- To avoid issues with CTAS or “select * into” queries, user can disable the setting at session level. The setting will be disabled only for these two operations.
- User can run “SET ROWSETLIMIT_LEVEL=0″ to disable the rowset limit to perform above operation. To enable set the value back to 1.
- To check the status of rowset limit at session level run “SHOW ROWSETLIMIT_LEVEL”.
- When we disable row set limit at session level and tru to create table using CTAS or select * into , then it will not be suject to row limit if the table being created is a database table. IF external table is being created then the row set limit will still apply.

Read more on Row set limit in Netezza…

↧

Nzstop vs Nzsystem stop

June 1, 2014, 9:33 am

≫ Next: Distributed Replicated Block Device (DRBD) in Netezza

≪ Previous: Row set limit in Netezza

Difference between nzstop and nzsystem stop?

Nzstop –> Stops Netezza immediatelly by kiling the currently running queries. This is the recomended command to stop Netezza.
NOTE: You can run nzstart/nzstop directly on server only. You cannot issue these commands from a client machine.

Distributed Replicated Block Device (DRBD) in Netezza

June 25, 2014, 10:20 am

≫ Next: screen command – Unix

≪ Previous: Nzstop vs Nzsystem stop

Distributed Replicated Block Device (DRBD) is a block device driver that can replicate disk, partition, blocks, etc across different Linus database hosts in a HA cluster environment. Here are some of the high-level details on how DRDB works in Netezza appliance.

↧

screen command – Unix

July 16, 2014, 6:49 pm

≫ Next: Netezza Thermal Fault Event – Known Bug

≪ Previous: Distributed Replicated Block Device (DRBD) in Netezza

If you are connected to you Netezza server remotely using Putty or similar tool and have to run large scripts which will return output to screen then you can make use of screen command so taht you can re-connect to the session incase your connection is lost.

Netezza Thermal Fault Event – Known Bug

July 27, 2014, 7:46 pm

≫ Next: Core files in Netezza

≪ Previous: screen command – Unix

Issue:
Thermal fault warning by TwinFin Server running on NPS v 6.0.5P5
NzEv-diskEncl Thermal_Fault 1122 @ 1st Rack, 7th DiskEnclosure for ServerName at 06-Nov-13, 01:14:22 EST

Exact Event Text:
Hostname ServerName
NzEvents 1
Event Thermal_Fault
Event Time 06-Nov-13, 01:14:22 EST
hwType diskEncl
hwLocation 1st Rack, 7th DiskEnclosure label slot-3 hwId 1122 currentValue $curValue errString Temperature reading is in missing state eventSource System initiated

↧

Core files in Netezza

August 1, 2014, 6:50 pm

≫ Next: Error – Record size limit exceeded

≪ Previous: Netezza Thermal Fault Event – Known Bug

Core file is generated when for some reason Netezza is not able to process some requests and hit some issue which result in Netezza server to dump all the contents of memory to a file for diagnostics purpose.

Error – Record size limit exceeded

October 2, 2014, 7:52 pm

≫ Next: How to find Netezza software support tools?

≪ Previous: Core files in Netezza

ISSUE:
You may get below error message when running a SQL query with REPLACE function.
ERROR: 229008 : Record size limit exceeded

DESCRIPTION:
You will face this error when you are using SQL extension toolkit version 1.6.1. It is a know defect 78087 reported with IBM and still there is no fix.

↧

How to find Netezza software support tools?

October 16, 2014, 5:23 pm

≫ Next: Netezza – InvalidateSharedInvalid: handled cache state reset

≪ Previous: Error – Record size limit exceeded

To find the current version of IBM Netezza Software support tools or support scripts (in general) run the below command:

head -n2 /nz/support/Version.txt

OUTPUT:

IBM_Netezza-7.0.2.3-130424-1831
NPS 7.0.2.3

This means we are on support tools version 7.0.2.3

↧

Netezza – InvalidateSharedInvalid: handled cache state reset

November 9, 2014, 5:33 pm

≫ Next: Case sensitive object name – Issue & Resolution

≪ Previous: How to find Netezza software support tools?

You may see messages like below in postgres logs (/nz/kit/log/postgres/pg.log):

DEBUG:InvalidateSharedInvalid: handled cache state reset

This is just a informational message and no action is required.
Reason why you see this message is because during system activity Netezza cache the catalog information. At a point in time when system finds that the catalog information cached is now obsolete it resets the cache information. When this reset happens it writes this informational message in postgres logs.

↧

Case sensitive object name – Issue & Resolution

November 18, 2014, 6:09 pm

≫ Next: How to read Resource Allocation Performance History (Nz Admin tool)

≪ Previous: Netezza – InvalidateSharedInvalid: handled cache state reset

ISSUE:
Getting error message like below, even when you can see the objects exists:
ERROR: Relation ‘TESTING’ does not exist
ERROR: Attribute ‘name’ not found

DESCRIPTION:
In Netezza we can create case-sensitive object names by enclosing the in double quotes (“”) while creating the objects. If object is not enclosed in double quotes then Netezza by default will consider it uppercase. Same is the scenario when we query these objects.

↧

How to read Resource Allocation Performance History (Nz Admin tool)

December 9, 2014, 7:37 am

≫ Next: Netezza – Max object id

≪ Previous: Case sensitive object name – Issue & Resolution

Group -> Name of GRA group
Allocated -> Min RSG set for a GRA group
Maximum -> Max RSG set for a GRA group
Allowed -> Based on the actual appliance usage the resources that a specific GRA group can get
Actual -> Actual resources that a GRA group is using
Short Jobs – Running -> Short running jobs (generally that take less than 2 sec)
Long Jobs – Running -> Long running jobs (generally that take more than 2 sec)
Short Jobs – Waiting -> Number of short jobs that went to waiting state because of GRA max for a group.
Long Jobs – Waiting -> Number of long jobs that went to waiting state because of GRA max for a group.

↧

Netezza – Max object id

December 26, 2014, 7:43 am

≫ Next: Sequence Caching in Netezza – Undocumented Feature

≪ Previous: How to read Resource Allocation Performance History (Nz Admin tool)

Maximum number of objectid’s accepted by Netezza is around 2.14 Billiion in V7 (around 1 Billion in V6). If your system start using OBJID greater than 1 Billion (in V7) then you will never be able to downgrade to NPS v6. Point to note here is that when ever you create any new object the object id increased and can never be reused even if you drop any objects. So object id allocation is always increasing.
Also note that objid count will increase by 10 when ever you create a table because internally 10 oids were reserved by NPS for table creation (look little strange but its true).

Read more on Netezza – Max object id…

↧

Sequence Caching in Netezza – Undocumented Feature

December 31, 2014, 7:32 am

≫ Next: How to find NPS versions ever installed on server

≪ Previous: Netezza – Max object id

Netezza have an undocumented feature (another undocumented Netezza stuff) that allows user to set the cache size instead of using the default which is around 100k. You should be thinking of using this feature if you heavily use sequences and also you perform a regular NPS restarts (like weekly vacuum, etc). In this scenario the sequence caching will help in reducing the wasted number of sequence keys thus lowering the risk of running out of max values.

↧

How to find NPS versions ever installed on server

February 9, 2015, 7:55 am

≫ Next: Netezza internal process – bnrmgr

≪ Previous: Sequence Caching in Netezza – Undocumented Feature

Check all the NPS versions ever installed on Netezza server. THis info also includes date time when this activity was performed as well as previous and new version for each upgrade.

↧

Netezza internal process – bnrmgr

February 24, 2015, 7:57 am

≫ Next: Netezza – How to failover a disk in TwinFin box

≪ Previous: How to find NPS versions ever installed on server

bnrmgr is on of the Netezza process which starts automatically when Netezza starts (All background processes are started by startupsvr background process). Main purpose of this process is to handle all the incoming requests for nzbackup and nzrestore commands. It launches a instance of backupsvr or restoresvr to handle each client instance.

↧

Netezza – How to failover a disk in TwinFin box

March 7, 2015, 7:59 am

≫ Next: How to read output of USAGE column for table $hist_table_access_1

≪ Previous: Netezza internal process – bnrmgr

Steps to failover a disk in TwinFin applicance:

1) If we have to failover a disk id# 1514, then first run below command to check its in which SPA.

nzds -id 1514 -detail
Data Slice Status SPU Partition Size (GiB) % Used Supporting Supporting Disks
Disks Locations
———- ——- —- ——— ———- —— ———- ———————
43 Healthy 1643 2 356 59.07 1514 spa1.diskEncl3.disk11
1535 spa1.diskEncl4.disk11
44 Healthy 1643 3 356 59.06 1514 spa1.diskEncl3.disk11
1535 spa1.diskEncl4.disk11

↧