IBM Cloud Docs
FAQs for NPSaaS

FAQs for NPSaaS

This is a collection of frequently asked questions (FAQ) about the IBM® Netezza® Performance Server for IBM Cloud Pak® for Data as a Service.

How do I migrate my users from On-Prem LDAP to NPSaaS and enable an external authenticator?

To migrate your users from OnPrem LDAP to NPSaaS and enable an external authenticator, follow these steps:

  1. Enable and configure an external authentication that you want to use on NPSaaS. For more information, see Managing authentication methods.

  2. Take a global backup on your on-premises system using the following command:

    nzbackup -globals -dir /nzscratch/OnPremGlobals

  3. Copy the backed-up globals directory to the target system.

  4. Before restoring the globals on the target system, verify the current user count and the latest user creation date on the source system by running the following queries:

    1. Get current user count:

      SELECT COUNT(*) FROM _v_user;

    2. Get latest user creation date:

      SELECT createdate FROM _v_user ORDER BY createdate DESC LIMIT 1;

  5. Restore the backed-up globals on the target system using the following command:

    nzrestore -globals -dir /nz/OnPremGlobals -npshost <sourcehost> -u <targetSystemUser> -pw '<targetSystemuserPassword>'

  6. After restoring the globals, verify the number of users added to the target system by running the following query:

    SELECT COUNT(*) FROM _v_user;

  7. Update the USEAUTH field for the newly added users by running the following query:

    UPDATE table_name 
SET use_auth= new_value 
WHERE usename IN ( 
   SELECT username 
   FROM table_name 
   WHERE CREATEDATE > <O/P captured in step 4b>
);

When configuring authentication, you will need to specify the authentication method you wish to use. The following options are available:

Authentication Methods:

  IBM IAM: 3
  Azure AD: 4
  LDAP: 5
  AWS IAM: 6
  SAML: 7
  OIDC: 8

To select an authentication method, simply replace new_value with the corresponding number for your chosen authentication method.

The number of updated users should match the number of users migrated.

How do I sign up for NPSaaS?

Create a free IBM Cloud account. When you have the account, you can provision a NPSaaS instance directly through the IBM Cloud® catalog. For more information, see Getting started with NPSaaS.

How do I generate or view credentials for my NPSaaS instance?

To generate credentials, follow the steps:

  1. Log in to IBM Cloud account.

  2. Go to Resource list > Services and Software > Databases.

  3. Click on your NPSaaS instance. You are now on the Service instance details page.

  4. Go to the Service Credentials tab.

  5. Click New Credentials.

  6. Type a name to assing to your credentials.

  7. Select the IAM role that was assigned to you to manage the instance.

  8. Click Add. If your credentials were generated successfully, you can view them now. Expand your credential entry. The following credentials were generated:

    • username: admin - Specifies a local database admin user that was created for you to access the instance.
    • password: xxxx - Specifies the password that you must use when logging in to your instance as admin.

    After you log in to your instance for the first time, change your admin password.

To view credentials, follow the steps:

  1. Log in to IBM Cloud account.

  2. Go to Resource list > Services and Software > Databases.

  3. Click on your NPSaaS instance. You are now on the Service instance details page.

  4. Go to the Service Credentials tab.

  5. Expand the credential entry that is associated with the credentials that you generated previously.

    • username: admin - Specifies a local database admin user that was created for you to access the instance.
    • password: xxxx - Specifies the password that you must use when logging in to your instance as admin.

    After you log in to your instance for the first time, change your admin password.

Now that I've generated credentials, how do I access my NPSaaS instance?

You can access your NPSaaS instance several ways, including a dedicated web console and a REST API.

For more information, see Connecting to Netezza Performance Server.

Can I set up spending notifications for my NPSaaS instance to keep track of my credit usage?

If you have an IBM Cloud® Pay-As-You-Go or Subscription account, you can set up email spending notifications. After your account is configured, you can configure spending thresholds and choose to receive notifications when you reach 80%, 90%, and 100% of the thresholds. For more information, see Setting spending notifications.

What's managed for me with NPSaaS?

IBM handles all of the software upgrades, operating system updates, and hardware maintenance for your NPSaaS instance. IBM also preconfigures NPSaaS parameters for optimal performance across analytical workloads, and takes care of encryption and regular backups of your data.

The service includes 24x7 health monitoring of the database and infrastructure.

In the event of a hardware or software failure, the service is automatically restarted. Because NPSaaS is a fully-managed SaaS offering, you do not get SSH access or root access to the underlying server hardware, and cannot install additional software.

Where can I find more information about NPSaaS?

  • In addition to the IBM Cloud documentation site, there is a wide range of information about the underlying NPSaaS engine functionality in the IBM Documentation.

  • Updates to the service are posted in the Release notes.

  • You can find pricing information one the IBM Cloud catalog page.

For more information, contact IBM Sales.

Where can I find help for a problem that I'm having?

For information about posting questions on a forum or opening a support ticket, see:

How can I change a Query History user's password?

You can change the Query History password in 2 ways:

  • using query editor
  • using remote nzsql client

Use the following SQL syntax with admin or any user with administrator privilege:

  1. Determine the name of the existing Query History configuration. The configuration name is the first field returned:
show history configuration

CONFIG_NAME | CONFIG_DBNAME | CONFIG_DBTYPE | CONFIG_TARGETTYPE | CONFI  G_LEVEL | CONFIG_HOSTNAME | CONFIG_USER | CONFIG_PASSWORD |  CONFIG_LOADINTERVAL | CONFIG_LOADMINTHRESHOLD | CONFIG_LOADMAXTHRESHOLD |  CONFIG_DISKFULLTHRESHOLD | CONFIG_STORAGELIMIT | CONFIG_LOADRETRY |
CONFIG_ENABLEHIST | CONFIG_ENABLESYSTEM | CONFIG_NEXT | CONFIG_CURRENT | CONFIG_VERSION | CONFIG_COLLECTFILTER | CONFIG_KEYSTORE_ID | CONFIG_KEY_ID | KEYSTORE_NAME | KEY_ALIAS | CONFIG_NAME_DELIMITED | CONFIG_DBNAME_DELI  MITED | CONFIG_USER_DELIMITED
-------------+---------------+---------------+-------------------+--------------+-----------------+-------------
  NZ_HIST   | HISTDB        |             1 |                 1 |              2 | localhost       |
TESTUSER    |
y5neWx3HuL2k$w5DqbqJOp+Y= |                     5 |
(1 rows)
  1. Create a configuration in which you disable Query history (with the HISTTYPE argument). For example, the following creates a configuration called hist_disabled:
CREATE HISTORY CONFIGURATION hist_disabled HISTTYPE NONE
CREATE HISTORY CONFIGURATION
  1. Update the system to use the hist_disabled configuration.
SET HISTORY CONFIGURATION hist_disabled
SET HISTORY CONFIGURATION
  1. Verify that the disabled Query History configuration is now active:
SHOW HISTORY CONFIGURATION

| CONFIG_NAME  | CONFIG_DBNAME | CONFIG_DBTYPE | CONFIG_TARGETTYPE | CONFIG_LEVEL |
| -------- | ------- | ------- | ------- | ------- |
| HIST_DISABLED |     |   3  |    1 |   1  | localhost
.
.
.
---------------+---------------+---------------+-------------------+--------------+----------
 HIST_DISABLED |               |             3 |                 1 |            1 | localhost       |             |
.
.
.
 (1 row))
  1. Make the required password changes in the original Query history configuration (nz_hist). In the following example, the user qryhist is assigned the password new_password.
ALTER HISTORY CONFIGURATION nz_hist USER qryhist PASSWORD new_password'
ALTER HISTORY CONFIGURATION
  1. Configure the system to use the initial configuration (nz_hist), which now has the changed password.
SET HISTORY CONFIGURATION nz_hist
SET HISTORY CONFIGURATION

  1. Stop and restart the database so that the system loads the original Query history configuration (nzstop/nzstart commands).

  2. Changes you make to a configuration only take effect after you restart the database. Load (activate) the disabled Query History configuration by restarting with the nzstop/nzstart commands.

  3. Verify that the correct Query History configuration is once again active with the SHOW HISTORY CONFIGURATION command.

For a complete description of each of the Query History commands, refer to the IBM Netezza Database User’s Guide.

How to check the name without using config name ALL_HIST?

Check your name by running below query:

 nzsql -c "SHOW HISTORY CONFIGURATION"

Steps for changing the current configuration and update the password.

  1. Set the current configuration to hist_disabled.

     nzsql -c "set history configuration HIST_DISABLED"

  2. Restart the database.

  3. Change the password as follows.

       nzsql -c "ALTER HISTORY CONFIGURATION <QUERYHIST> PASSWORD '<new password>';"

  4. Set the current configuration to your current history database file. If all_hist is your configuration then change it as follows:

       nzsql -c "set history configuration all_hist"

  5. Restart the database.

Open a ticket to stop and start the database when resetting history user password.

How far can prolife be scaled up?

From NC-START, we can scale up the workload contour to NC0.

How much can storage be scaled up from an NC-START configuration with 400 GB storage density on AWS?

Within the NC-START workload contour on AWS, storage can be scaled up to 1200 GB. If you choose to scale further into the NC0 contour, storage density can range from 2400 GB up to 24000 GB. Similarly, for an NPS instance deployed on Azure, the base storage is 256 GB. This can be scaled up to 1024 GB within the NC-START workload contour. Scaling to the NC0 contour allows storage density to range from 1536 GB to 12288 GB.

What is the maximum storage scaling limit?

Within the NC-START workload contour, storage can be scaled up to 1200 GB. However, if you also scale the workload contour to NC0, storage capacity can be increased from 2400 GB up to 24000 GB.

What is the procedure for scaling up from the NC-START configuration??

To scale up from the NC-START configuration, please follow the guidance provided in the documentation links below: To increase storage within the NC-START workload contour (currently at 400 GB), see: NC-START Storage Scaling Guide. To scale the workload contour from NC-START to NC0, see: NC-START to NC0 Contour Scaling Guide.

Is it possible to scale up without affecting the current database configuration and data?

Yes, you can scale up while preserving the current database configuration and existing table data.

After scaling up profile to NC0, is it possible to revert to NC-START?

No, once you scale up from NC-START to NC0, you cannot revert to NC-START.

Is it possible to scale down storage after increasing it from 400 GB?

No, once storage has been scaled up, it cannot be scaled down.