Planet Ingres

The Ingres VectorWise beta program garnered a lot of interest from existing Ingres customers and partners and from shiny new prospects looking for a BI solution that could provide real-time analytics without breaking the bank.   In a couple of cases the beta roll-out was stalled pending approval and procurement of hardware.   Getting feedback from real-world scenarios is crucial to the success of any new product so we needed to look ‘outside the box’ (excuse the deliberate pun) to keep the momentum going.   We immediately thought of setting up a pre-configured AMI with everything needed to get started with Ingres VectorWise, but we were concerned that perhaps the performance of cloud storage would be an issue.   After some testing with various data volumes on Amazon’s EBS we were delighted to note that the performance was far better than predicted to the point of being an acceptable platform for Ingres VectorWise deployment.   We had a number of our beta sites test in the Cloud and the feedback we received was very positive.  

Given our success with the Amazon EC2  the obvious next question was what about private clouds, other public clouds, hybrid clouds where part of the infrastructure is in a private cloud and part in a public cloud, the scenarios were endless.   To build solutions for all of the various combinations was going to be time consuming and time is money!  

A few weeks ago during one of our regular calls with Red Hat re our Cloud Foundations collaboration mention was made of a new innovation that would allow us to pre-assemble the components we wanted to include in our machine image and choose the deployment platform from within the development environment.  This will greatly speed-up and simplify the production and testing of Ingres solutions for all of the various cloud types and provide a flexible platform for innovation.   

The massive demand for mobile applications has resulted in the need for a reliable and scalable platform to support these applications and the cloud provides that platform.   Embracing the production of standards in collaboration with others, who know what it means to build business critical applications, will mean that whether you use mobile applications to close that next big deal, or to find the nearest happy-hour, the technology stack behind it will ensure your needs are met.

Related Links:
http://blogs.ingres.com/ketankaria/2010/08/25/opening-in-the-cloud/

http://press.redhat.com/2010/08/25/red-hat-paas-build-any-way-deploy-anywhere/

http://www.ctoedge.com/content/red-hat-expands-cloud-portfolio

 

In theory cloud computing should be a development playground for Ingres’ partners and customers.  By its very nature open source and innovation should be at the heart of cloud computing, however in the past few months I have started to become concerned that actually the cloud could be “the mother of all lock-ins”.

That term came from a conversation with Jim Whitehurst, Red Hat’s CEO.  He is worried, as we at Ingres are that enterprises could fall into the traps that proprietary monoliths lay to get them signed up to a technology infrastructure which has no easy way out, huge integration issues and low investments in development.

Our cloud announcement with Red Hat has therefore given me hope.  We hear from our ISV partners and customers that they want a cloud ‘stack’ that doesn’t compromise on the interoperability, open standards and innovation that they have come to expect, having worked with the likes of Ingres and Red Hat for many years.

I am looking forward to seeing the cloud develop in a more open, standardised and innovative way, thanks to initiatives such as the Cloud Foundation.  We have hopefully dodged an industry bullet by partnering and sharing innovation to provide a cloud vision that enterprises thrive within.

We've been asked enough times lately what FOSSLC is that I was thinking a short blog on this topic might be a good idea. We've evolved from where we started a few years ago so it's worthwhile to see what it is we do today.

Our tag line is pretty accurate: FOSSLC is a non-profit corporation dedicated to education, community, and business development involving open source technologies. But what does this *really* mean?

read more

Ingres’s OpenAPI C interface can be challenging at times especially when it comes to debugging or reading an API trace. For example, right now I’m trying to debug a problem in the PHP driver for Ingres. For some reason during the tear-down of the request the driver is unable to close a statement. Turning to a level 5 API trace I get this. Which, to be honest has information in there that I don’t exactly need. Specifically I’m not too interested in the calls to IIapi_wait() [1] or the lower level Dispatch() functions. With this in mind using grep I can filter out this “chaff”, and produce a more concise log file:

grep -v "IIapi_wait\|Dispatch" api.log

Turning this into:

!IIapi_initAPI: initializing API.
!IIapi_initialize: INGRES API initialized, envHndl = 090F9308
!IIapi_initialize: startup API
!IIapi_initialize: version = 6
!IIapi_initialize: INGRES API initialized, envHndl = 09078018
!IIapi_connect: connect to DBMS Server
!IIapi_connect: envHndl = 09078018, connHndl = 00000000, tranHndl= 00000000
!IIapi_connect: target = @server,tcp_ip,ii[user:secret]::dbname
!IIapi_thread(-1226205472): allocated local storage 091A5E78
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_setEnvParam: set environment parameter
!IIapi_setEnvParam: envHndl = 09078018
!IIapi_setEnvParam: paramID = 24.
!IIapi_autocommit: set autocommit state
!IIapi_autocommit: connHndl = 091A5960, tranHndl = 00000000
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_query: starting a query
!IIapi_query: connHndl = 091A5960, tranHndl = 091A69B8, queryType = 0
!IIapi_query: queryText = set session with description='hello'
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_close: closing a query
!IIapi_close: stmtHndl = 091A8070
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_query: starting a query
!IIapi_query: connHndl = 091A5960, tranHndl = 091A69B8, queryType = 0
!IIapi_query: queryText = set lockmode session where readlock=nolock
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_close: closing a query
!IIapi_close: stmtHndl = 091A6580
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_cancel: cancelling a query
!IIapi_cancel: invalid handle
!IIapi_appCallback: request completed, status = INVALID_HANDLE
!IIapi_close: closing a query
!IIapi_close: invalid statement handle
!IIapi_appCallback: request completed, status = INVALID_HANDLE
!IIapi_autocommit: set autocommit state
!IIapi_autocommit: connHndl = 091A5960, tranHndl = 091A69B8
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_disconnect: disconnecting a connection
!IIapi_disconnect: connHndl = 091A5960
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_releaseEnv: Release Environment
!IIapi_releaseEnv: envHndl = 09078018
!IIapi_terminate: shutdown API
!IIapi_releaseEnv: Release Environment
!IIapi_releaseEnv: envHndl = 090F9308
!IIapi_terminate: shutdown API
!IIapi_termAPI: shutting down API completely.
!IIapi_termAPI: API shutdown.

A lot simpler to read – Now I can see that a bad statement handle has been passed to IIapi_cancel() and IIapi_close(). Now I know what the problem is it’s time to find where the statement handle is coming from.

[1] It should be noted that you cannot always discount IIapi_wait() calls. A number of years ago I hit a weird timing issue due to a missing IIapi_wait() call.

Related Posts

• Improving the Improved – docs.ingres.com
• Ingres VectorWise Webinars
• IUA VectorWise Demo Video

I have been repeatedly installing different builds of the Ingres 10 beta for testing with the Ingres Hibernate dialect and in my quest to be lazy I have been performing minimal installs by hand.  My recent post Ingres Package Install Ain’t Misbehavin mentions the change in behaviour of a manual package installation that I fell foul of.  I was looking around for references to a command line package installation, but unfortunately I couldn’t find any,  so I wrote some notes Command line RPM installation as an aide mémoire.

Related posts

• Ingres package install ain’t misbehavin
• Ingres doc search plug-in updated
• Ingres Documentation site relaunched
• Cloudy with Ingres VectorWise
• UK IUA 2010

Following on from the post Ingres documentation site relaunched I’ve updated the search plug-in and created the Ingres doc search plug-in page.

Related posts

• Ingres Documentation site relaunched
• Ingres command line RPM installation
• Ingres package install ain’t misbehavin
• Cloudy with Ingres VectorWise
• UK IUA 2010

As noted elsewhere this week saw the relaunch of the Ingres documentation site http://docs.ingres.com. At last we have the ability to deep link into the documentation without having to do acrobatics to extract links in the docs, for example

http://docs.ingres.com/Ingres/9.3/Database%20Administrator%20Guide/largedataloadswsetnologgingstatement.htm

has become

http://docs.ingres.com/ingres/9.3/database-administrator-guide/1757-large-data-loads-with-the-set-nologging-statement

To get the URL for the first required some navigation of the documentation index, via the tree or via the search engine. Since Google is used by many people as their home page, even to search for facebook.com it makes more sense that the documentation is more accessible from Google, Bing et. al.

One of the downsides with the new docs.ingres.com site is the use of screen real-estate. The main ingres.com properties have their content squeezed in to 980px which is ok in the 1990 world of “This website supports 1024×786″ resolutions. However in this day and age I would make the supposition that 1280×1024 would be more common, something that’s borne out by Valve Software’s monthly hardware survey. With the increasing trend towards wide-screen displays in laptops as well as desktop displays a 1440×900 resolution will become more common.

With this in mind I’ve put together a couple of hacks that when used with Google Chrome or the Firefox Greasemonkey addon – increases the amount of space used for the content to 60% of the width of the browser window. To install, click on the relevant link for your browser – note that the Greasemonkey script can be used with Google Chrome (from 4.0 onwards).

• Google Chrome – http://planetingres.org/~grant/bigdocs/bigdocs.crx
• Firefox with Greasemonkey – http://planetingres.org/~grant/bigdocs/bigdocs.ingres.com.user.js

Once installed go to any docs.ingres.com page and after the page finishes loading the content area will be super-sized. If there’s any interest I’ll look into to how the page can be rendered full size without having to expand on screen.

Related Posts

• Ingres Documentation Search
• Ingres VectorWise Webinars
• IUA VectorWise Demo Video

Over the last couple of days I’ve done couple of Ingres installations using the latest, bleeding edge, RPMs and have come across a change in behaviour that might catch you out, as indeed it did me. What follows is a more or less verbatim copy of the output from an install of the latest SVN head revision I performed earlier today:

[grant@usrc-git T1]$ sudo rpm -ihv ingres-32bit-T1-10.1.0-00.x86_64.rpm ingres-dbms-T1-10.1.0-00.x86_64.rpm ingres-odbc-T1-10.1.0-00.x86_64.rpm
ingres-T1-10.1.0-00.x86_64.rpm ingres-net-T1-10.1.0-00.x86_64.rpm
[sudo] password for grant:
Preparing...                ###########################################[100%]
    1:ingres-T1               ###########################################[ 20%]
    2:ingres-32bit-T1        ###########################################[ 40%]
    3:ingres-dbms-T1       ###########################################[ 60%]
    4:ingres-odbc-T1        ###########################################[ 80%]
    5:ingres-net-T1          ###########################################[100%]
Building the password validation program 'ingvalidpw'.
Executable successfully installed.
[grant@usrc-git T1]$ sudo -u ingres -i
Release                     Running Script II_SYSTEM
-------------------------------------------------------------------------------
II 10.1.0 (a64.lnx/100)NPTL    N    loadII /opt/Ingres/IngresII
II 10.1.0 (a64.lnx/00)NPTL     N    loadT1 /opt/Ingres/IngresT1
[ingres@usrc-git ~]$ loadT1
[ingres@usrc-git ~]$ ingstart
Ingres/ingstart
No Ingres servers have been configured to start up.
[ingres@usrc-git ~]$ iipmhost
localhost
[ingres@usrc-git ~]$ ingprenv
II_INSTALLATION=T1
II_HOSTNAME=localhost
II_SHADOW_PWD=/opt/Ingres/IngresT1/ingres/bin/ingvalidpw
[ingres@usrc-git ~]$ cat /opt/Ingres/IngresT1/ingres/files/install.log
Installing Terminal Monitor utility files...
[ingres@usrc-git ~]$

Prior to Ingres 10.1, the RPM install scripts would perform the post-laydown configuration. As of 10.1 this is no longer the case as you can see from the output above. The 10.1 RPMs only lay down the files and do minimal configuration, which sets up the symbol table as per the output from ingprenv. Ingres now gets configured when started as a service for the first time:

[grant@usrc-git T1]$ sudo service ingresT1 start
Ingres, instance T1 has not been setup
Running setup for Ingres 10.1.0-00...
	Running setup for dbms...                                        OK
	Running setup for net...                                         OK
	Running iisusupp32...                                            OK
	Running iisudbms...                                              OK
	Running iisuc2...                                                OK
	Running iisutux...                                               OK
	Running iisuodbc...                                              OK
	Running iisubr...                                                OK
	Running iisudas...                                               OK
Starting Ingres, instance T1:                              [  OK  ]
[grant@usrc-git T1]$

Leaving us with a configured and running installation.

Some random posts