Striim Subscription

Our main use case for Striim is real-time data integration and change data capture, which we used to pull live transaction logs directly from IBM DB2 and stream them seamlessly into our modern cloud data warehouses.

A specific example of how we used Striim in our project is when we were migrating data to new and modern cloud data warehouses from IBM DB2 where we used the CDC feature of Striim. Real-time data integration and the CDC feature really helped us in that project.

From a BA perspective, our business users basically needed instant access to the live production data for analytics, which we provided them by using Striim. As a developer, I would say our bottleneck was that running heavy query workloads directly on the mainframe threatened our SLA transaction windows, so Striim helped in that perspective also.

The best feature that Striim offers in my experience is the dedicated IBM DB2 for z/OS connectors, which I really appreciated because it reads database logs directly, meaning we do not have to write custom extraction programs or alter existing application codes.

Using those dedicated connectors impacts our workflow by capturing instantly at the log level and streaming them out to the mainframe to cloud warehouses in real-time. In our organization, the real-time data is very important; any delay or wrong data transferred would impact a huge amount or cost to the company. It reduces the complexity of mainframe data format into clean streams and also reduces the time, and since it is real-time, it really helps us to transfer that real-time data.

Striim has positively impacted my organization by reducing the cost of doing it manually or through some other process for that particular project. By offloading analytics queries from the mainframe and utilizing log-based CDC, we drastically reduced our MIPS consumption, which is the mainframe CPU consumption and computing overhead during peak business hours. This reduction in MIPS reduced the overall cost.

I think the initial schema mapping tool in Striim can have a learning curve when dealing with deeply nested mainframe structures or complex copybooks. A more automated, BA-friendly interface for mapping would be a great addition.

I have been using Striim for one of our projects, which lasted for one and a half years.

In my experience, Striim is mostly stable; for that particular project, I had never seen any issues with the stability.

Striim is quite scalable.

The customer support has been excellent, and their engineers actually understand z/OS architecture and DB2 logs, which made troubleshooting during the initial setup smooth.

I personally have not used a different solution before Striim, but my organization may have been using a different solution previously. For me, it was my first project where I had to move data from mainframe DB2 to new data modern warehouses, so I have not personally used anything else.

I have seen a return on investment from using Striim, as I look for a system that requires minimal maintenance. Striim's continuous pipeline safely processes millions of daily transactions without data loss; my organization had millions of transactions every day and even in real-time, so it was quite good. We had saved a lot of money by reducing the MIPS, making it a good ROI.

We evaluated other options before choosing Striim, including building in-house ETL programs and traditional batch replication tools, but they were ruled out because they either put too much CPU load on the mainframe or could not deliver the real-time data. We chose Striim because it could deliver both reduced CPU consumption time and real-time data without any errors.

I rate Striim an eight out of ten, as it satisfies business requirements for real-time data while strictly protecting our mainframe performance and transaction speeds.

I chose eight out of ten because there are a few disadvantages, such as a few features that might be good, including the initial schema mapping tool that can have a learning curve when dealing with deeply nested mainframe structures or copybooks. As a BA perspective, a friendly interface for mapping would be good.

The accuracy of Striim is quite good; we tested it by matching the values we had in the mainframe system, and after loading into the new and modern data warehouses, the accuracy was great.

My advice to others looking into using Striim for mainframe development or modernization is to ensure that your mainframe developers and BA collaborate closely from day one. I suggest pre-defining your target cloud schemas and business rules so you can immediately unlock the power of that real-time stream.

Striim acts as the perfect modern bridge for legacy environments, keeping both our development teams and business stakeholders happy. We were happy to use Striim for that particular project, and I hope we can use it further. I also hope that the few features I would like to see added are integrated, so we can use it seamlessly.

We use Striim to replicate the warehouse data to Google platform to generate reports.

We have developed a centralized server where we pull all the warehouse data through Oracle GoldenGate. Striim sits on Google Cloud Platform and the Striim agent connects to the compute server, reads the files generated by GoldenGate, and replicates the data. Additionally, we have Striim agent running on a standalone server that connects to OCI, reads the trail files from Oracle GoldenGate, and sends the data over to Google Cloud Platform.

Our aim was to use Striim to get the reports from Google Cloud Platform and it is working effectively, so Striim is useful for that purpose.

Striim is definitely my data migration tool and data reflection syncing tool. It reduces manual intervention because it automatically syncs the data from the warehouse. We can get the reports dynamically in real-time data reports. This saves time and helps to improve the business by analyzing the latest data.

We use Striim for normal BI. We do not use much workflow, though we have configured this workflow.

Striim is very easy to configure. You just install an agent and then configure it to connect to your server. Once the connectivity works fine, it is fairly a simple way to use Striim.

I would say Striim performance needs improvement because we use more GoldenGate, so I tend to compare GoldenGate with Striim. Comparing GoldenGate, I feel Striim will struggle a little bit when a batch process runs for a longer time and generates too much data. Otherwise, Striim is acceptable. With respect to certifications, I feel Striim is more expensive in terms of licensing. However, it is good if it is compatible with the product that we use.

Striim could provide more transparency in terms of the log files. When there is an issue, whenever there is an agent problem, we have to reach out to the Striim development team. If they were more transparent with their logs, we could debug and analyze ourselves. Additionally, they could provide more features with less licensing cost.

Documentation and compatibility are fairly straightforward. However, they could improve the documentation by showing how to configure with different platforms. Sometimes we rely on the development team to provide us with instructions whenever there is an agent issue. If there were more detailed documentation available, we could follow that and try to resolve the issues ourselves.

Striim is stable.

Striim can handle the data volumes effectively, but it can struggle a little bit if the data volume is too high.

If the transactions are not too frequent and if there are no long batch jobs, I would suggest going for Striim. If the data volume is comparatively moderate, I would recommend Striim.

Customer support is fairly good. When you contact them, they give you a response straight away and help you identify the issue and fix it. There is no problem with the customer support.

We used Oracle GoldenGate, and we switched to Striim because we wanted to use it in Google Cloud Platform.

The initial setup was straightforward.

I would say Striim saves time as it syncs the real-time data. Employees do not need to be dedicated to reviewing or monitoring Striim. The data team that you have in your company are the ones needed to see the data. No specific employees are needed to handle Striim.

Licensing was a bit more expensive because Striim has to read from Oracle GoldenGate trail files and also integrate them. However, I have no idea how much it was because I was not involved in that part.

We chose Striim as the first option.

The interview process is fairly good and covers all the questions about the product that the customer wants to know. This review has an overall rating of seven.