Using Google Chrome?

Download my
free Chrome Extension, Power Notes Searcher, to make searching for and evaluating SAP notes, much easier.

Recent Posts

Thursday, November 27, 2014

Netgear ReadyNAS Duo Samba Performance

If you access your Netgear ReadyNAS Duo via your Windows Explorer and you think it's a little slow when reading/writing, then you could get a little speed boost from adding one line to the Samba configuration.

You'll need access as root via SSH to log into the ReadyNAS.

Backup the current config file:

# cp -p /etc/samba/smb.conf  /etc/samba/smb.conf.bak

Then as root, edit the samba config file:

# vi /etc/samba/smb.conf

Add the new line under section "[global]":

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536

Save the file (ZZ).

Restart Samba:

# /etc/init.d/samba restart

Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.

You should notice a performance improvement when transferring files.

Thursday, November 20, 2014

Secure ReadyNAS Duo (v1) ADMIN Share

If you have a ReadyNAS Duo and you're happy with your setup and are now sharing your shares out through your router over the internet, you need to be aware that any old hacker can try and access your ADMIN share (e.g. https://<your-readynas>/admin).

I use mine in exactly that way but don't want Mr A.Hacker trying out a myriad of passwords on my ADMIN share just because my public shares have "Netgear ReadyNAS" plastered all over the front page (a tip for another day I feel).

Instead, if you're comfortable using SSH, (there is a way to do this by using the FrontView config backup, edit the file and put back in place) then you can edit your Apache httpd.conf configuration file so that access to the ADMIN share is restricted to a host or hosts on your local home network only.

Steps:

1, Log into your readynas via SSH as root.
2, Backup your old config file:

# cp -p /etc/frontview/apache/httpd.conf  /etc/frontview/apache/httpd.conf.bak

3, Use 'vi' to edit the httpd.conf:

# vi /etc/frontview/apache/httpd.conf

4, Change the sections as follows:

<Location /admin>
DirectoryIndex index.html
Options ExecCGI
AuthType Basic
AuthName "Control Panel"
require user admin

# block external admin.
Order Deny,Allow
Deny from all
Allow from 192.168 <<< INSERT YOUR LOCAL NETWORK IP ADDRESS SUBNET HERE
</Location>

and

<Location /get_handler>
SetHandler perl-script
PerlHandler get_handler
PerlSendHeader On
Options ExecCGI

# Order allow,deny
# Allow from all
AuthType Basic
AuthName "Control Panel"
require user admin

# block external admin.
Order Deny,Allow
Deny from all
Allow from 192.168 <<< INSERT YOUR LOCAL NETWORK IP ADDRESS SUBNET HERE
</Location>

plus

<Location /dir_list>
AuthType Basic
AuthName "Control Panel"
require user admin
Options ExecCGI
#Allow from all

Order Deny,Allow
Deny from all
Allow from 192.168 <<<-- Insert your subnet here.
</Location>

5, Save the changes with:

<shift + 'ZZ'>

6, Restart your readynas:

# shutdown -r now

7, Test from your local network that you can access the ADMIN share:

https://<readynas IP>/admin

8, Test from the internet that you can't access the ADMIN share:

https://<ISP IP>/admin

You should see a HTTP 403 FORBIDDEN error.

That's it.
If you made an error, you can restore your config from the backup file you took:

# cp -p /etc/frontview/apache/httpd.conf.bak /etc/frontview/apache/httpd.conf

and then restart your readynas.
Don't forget to check the config after you make any changes to shares / firmware etc.

Thursday, November 13, 2014

SAP Kernel to EXT or not to EXT...

Scenario: You're at the point where you are installing a new system and your choice of Kernel is down to the EXT version or the non-EXT version.  Which version should you use?

The difference between the EXT version of a Kernel and the non-EXT version of a Kernel, is simply down to the version of the compiler and compilation Operating System used by SAP to compile the Kernel binaries.

As an example, the 7.21 kernel could be compiled on Windows 2003 Server, using the Visual Studio 2010 compiler.
The 7.20EXT kernel could be compiled on Windows 2003 Server, using the Visual Studio 2012 compiler.

The difference is all about the compilation environment, and nothing to do with functionality.  Or is it...
If you look at SAP note 1926209 - "Questions on subjects of 7.20/7.21 EXT kernel and C/C++ runtime", this would seem to be the case.
However, read SAP notes 1756204 - "Activate fast polling"  and 1728283 - "SAP Kernel 721: General Information" , you will see that it seems to suggest that SAP can and will change the functionality between an EXT and non-EXT kernel (7.21 is used as the example here).
So, be wary and always read up about the benefits of each Kernel, whether EXT or not.

Thursday, November 06, 2014

IBM DB2 10.1 Statistics Replication

Scenario: You would like to test a new index in an IBM DB2 10.1 database.  Unfortunately your development system doesn't have anywhere near the same number of records in the database table on which you are creating the new index.

Like many other RDBMSs, DB2 uses table and column statistics to influence the optimiser's decision as to which access path to choose at execution time.
By replicating only the statistics, it's possible to fool the optimiser into thinking the table has more records present, than it really does.  This means that it's likely to choose a different access path.

When performance tuning a database, it's useful to use this method of fooling the optimiser, because you can emulate a larger table in a small development system with little actual data.

The process in DB2 is like this:
- Generate (or export) the statistics for a table in a production database system (PRD) schema DBA.
- Modify the export file.
- Upload the contents of the export file into a development database system (DEV) schema DBB.
- Test.

Step 1 - Export the statistics for a table in production.

Connect into the production database (DBA), then use the db2look command to create an export file containing the UPDATE commands for adjusting the statistics:

db2prd> db2 connect to PRD

db2prd> db2look -d PRD -e -c -m -r -t DBA.TABLE1 -o table1_STATS.sql

The output will be written to the table1_STATS.sql file in the current directory.

Step 2 - Modify the export file.
You should edit the output file to remove all lines before the line “-- Mimic table TABLE1”, failure to do this could mean dropping the TABLE1 table in development.

You must also edit the file and replace all instances of schema “DBA” with “DBB” to ensure that the correct development database schema is found.
The modified file will look like:

-- Mimic table TABLE1

UPDATE SYSSTAT.TABLES
SET CARD=2341434,
NPAGES=14636,
FPAGES=14645,
OVERFLOW=9473,
ACTIVE_BLOCKS=0
WHERE TABNAME = 'TABLE1' AND TABSCHEMA = 'DBB';

UPDATE SYSSTAT.COLUMNS
SET COLCARD=1,
NUMNULLS=0,
...

Step 3 - Upload the statistics into the development database.

db2dev> db2 connect to DEV
db2dev> db2 -tf ikpf_STATS.sql
...
DB20000I The SQL command completed successfully.

DB20000I The SQL command completed successfully.

SQL0100W No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. SQLSTATE=02000

SQL0100W No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. SQLSTATE=02000

You're now ready to test.

To reset (re-gather) the statistics on the development database table, you simply need to re-collect statistics using the RUNSTATS command: "db2 RUNSTATS ON TABLE TABLE1 WITH DISTRIBUTION AND INDEXES ALL".