Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For an existing web application built on using Oracle database, what are the choices available in order to scale horizontally. Few thoughts are:
Have multiple databases and multiple application servers each connecting to a different database and a controller application with his own database whose role will be to decide which request to send to which server. Challenges involve moving existing data from one database to another as and when required in order to evenly distribute the load on multiple databases. Also keeping all the common data on all the database in sync with the controller database.
Move to NoSql
Any other?
Please suggest.
The standard approach to horizontally scaling an Oracle database is to use Oracle Real Application Clusters (RAC). RAC allows you to have a single database on a shared file system (i.e. a NAS or a SAN) that is mounted by multiple different instances running on multiple different database servers simultaneously. Oracle takes care of keeping the data in the caches of the various nodes in sync.
If you are using the enterprise edition of Oracle, RAC is an extra-cost option (you'd need to speak to your Oracle Sales rep to get a quote). RAC is included with the standard edition (though the number and size of machines you can have in a standard edition RAC cluster is limited).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have an Oracle DB with data in onPrem and Azure Postgresql DB in cloud.
I really need data changes in Oracle to be reflected as near to real-time as possible in Azure Postgresql DB.
I need data changes in Azure Postgresql DB to be reflected as near to real-time as possible in OnPrem Oracle.
See the below diagram for more info.
I am new to Azure-Postgresql.
I would appreciate any suggestions / insights.
Just for now, there isn't a directly way to sync the data between on-premise Oracle database and Azure PostgreSQL database. You need use other ETL ways.
Per my experience, you can think about use Data Factory.It's used to transfer the data to achieve the data sync. You could follow this way:
Create a pipeline to copy the data from on-premise Oracle to Azure
PostgreSQL.
Create a schedule trigger to run the pipeline, we can set the
execution every 5 mins.
For on-premise dataset, you also need self-hosted integration runtime.
Ref the tutorials:
Copy data from and to Oracle by using Azure Data Factory
Copy and transform data in Azure Database for PostgreSQL by using
Azure Data Factory
You need to think about the cost and if it's acceptable to you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Our firm has a rather complex proprietary Access database system including 15 or so unique front end modules that all perform different tasks and a backend database for each of our clients. All of these front end modules and backend databases have many SQL queries, functions, macros, and VBA code. We are considering upgrading to SQL Server or an equivalent but I see several major pitfalls including the incompatibility with VBA and Access functions. Do you think it would make more sense to stay with Access and look into improving via 1. accde/mde or accdr/mdr 2. split databases and/or 3. merging/consolidating front end modules? Do some of you have experience with such an upgrade or have any other recommendations?
You should consider migrating tables to SQL Server and keeping the Access Front-end. SSMA For Access will move the data and replace the tables with ODBC linked tables for you.
Then, moving forward, you can continue to use Access or build applications using other tools.
It is assumed that you run front ends with linked tables to the back end accDB file.
You then can migrate that database to sql server, you migrate only the data part.
The access FE (front end) should work as before - about 99% of the code and forms will work as before, but some tweaks are often required. Given that SQL express is free, then it is great setup and will allow you to keep and preserve most of your existing software investment
However, on each workstation, you are placing a FE of the application on that workstation. You as a general rule can't allow multiple users into the same given FE - it is to be placed on each workstation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have few tables that I have to sync between 3 different RDBMS systems (PostgreSQL databases, a SQL Server and a Firebird Database).
Currently I simply connect to my Firebird database and pull the few relevant tables to my PostgreSQL database, but as databases change, new tables require querying and with the addition of a SQL Server database to the mix I feel this solution is ill fitting.
I've done some research on BI tools , but I still need to query data from this data source and show them inside a Windows Forms application.
PS: it's not a migration and I only need to query the data from these "satellite" databases
Using PostgreSQL as your hub, you can use Foreign Data Wrappers to reach out to the other two databases whenever a query wants their data. Then it will always be up to date, but performance might suffer compared to actually importing the data. For reaching SQL Server, you can use tds_fdw, and for firebird you can use firebird_fdw. I have never used either one of these, so this is just a starting point.
You could probably pick SQL Server as your hub and accomplish the same thing, it calls them "linked servers" rather than Foreign Data Wrappers, see for example.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have created a simple (commercial) WPF application and want to distribute it with a database that can be installed on the local machine of a customer.
What database is the best to use ?
I was considering SQL Server Epress Edition 2008. I know the limitations of 10 GB, but that's more than enough and is no issue.
The only thing I'm not choosing 100% for Express is that I don't know how to let my customer backup the database.
My collegues keep telling me to use MS Access, but I don't know if that's a good option because I want to use stored procedures and views.
Please let me know what you are using or you can advise me...
SQLite is a great alternative. There is an ADO.NET provider developed by System.Data.SQLite
And there is a decent, free, editor for SQLite as well: SQLite Administrator
Backing up is as easy as copying the SQLite db file. Really.
What is the estimated amount of data?
For small databases SQLite may be an good choice - it is light, fast, opensource and needs no additionally software. It even supports encryption, if you need that.
Backup is as easy as it could be, as the SQLite-database consists of a single file.
Ruutert: database-size up to 500 mb:
That size should be no problem for SQLite. We use databases up to several GB. Only problem on big databases is, that vacuum (like reorg / compress unused space) takes as longer as bigger the database is (but that is the same for other database-types)
Ruutert: disadvantages of SQLite?
You could get problems with High Concurrency (lots of parallel database-access). Also I would consider an client-server oriented database-manager if your workload is so heava that you think about moving your database-manager to another server - splitted from application-server.
But as you considered using SQL Server Express or MS-Access, which have limited functionality too, that should not be the problem. On the other side you have the advantage that you need just an small dll (or compile it static into one of you own) instead of installing an complete database-manager.
An embedded database (like SQLite, which others answerers already mentioned) sounds like the right choice for you.
Since you're using .net anyway, how about Microsoft's SQL Server Compact?
(also an embedded database)
SQL-CE does not include stored procedures.
SQLite is usually the chosen one. However, there is also VistaDB.
You could always look into NoSQL or OO databases:
db4o
RavenDb
EloqueraDB
Note that some of these may need separate DLLs in order to expose the providers in .NET code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I was asked to provide an estimation to change a relatively small app designed with MS Access to use a SQL database.
First, is this even possible? I never worked enough with Access, so I'd like to know. If it's possible can you please point me to some websites with tutorials regarding this?
Second: if it's possible, is it recommended? Is it a big performance hit? Any specific do/donts that you can and want to share?
Thanks in advance for your help.
SQL Server upsizing is relatively easy to do although thorough testing is required. I'd estimate the effort at 5% to 10% of the initial system development. SQL Server upsizing is recommended in specific circumstances such as greater than 25 to 50 users or 24x7 access or difficulty/impossibility in rekeying data in the event of a corruption.
See my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page
There is a tool from the SQL Server group SQL Server Migration Assistant for Access (SSMA Access) which is a lot better than the upsizing wizard.
For the specific task of converting a Microsoft Access database to use SQL Server as the back-end data store while keeping the user interface from the Microsoft Access application, Access itself supplies an "Upsizing Wizard" (Tools | Database Utilities | Upsizing Wizard).
This wizard will step you through the process of connecting to an instance of SQL Server, creating an SQL Server database, and moving, to the greatest extent possible, your tables and views (called Queries in Access) to the new database.
The process can be relatively painless, or fraught with difficulty depending on numerous factors including how well you've validated your data in the Access database, whether you've made use of VBA functions in your queries, and whether you've used any query constructs unique to Access.
This tells you how to convert Access to SQL Server:
http://support.microsoft.com/kb/237980
Now, depending on how the application was written (language, etc.), the rest of it may be a quite a bit more work. However, it's really difficult to throw a ballpark on that one because the number of variables in this are large. In any case, it is possible, so that's not an issue.
In terms of performance, if the database is tiny, then Access may actually be faster. If the database is large, you'll gain from SQL server. Aside from that, you can have distributed clients and one data store centrally located, that's a plus.
By the way, if this is written using the .NET framework, it probably just got a lot easier.
This would be fairly easy to do (hopefully). In Access, you can create linked tables that are just links through to tables in other database (like SQL Server), so you could take your existing apps and replace all the Access tables with same-named links to tables in your SQL Server database.
I think doing this could be the opposite of a performance hit, depending on the circumstances. Access is very performant, but only with a small number of concurrent users (say, less than 30). So if the application has a large number of users, you would benefit from switching over to SQL Server. If, however, the SQL Server database is hosted on a different machine, than you lose performance by connecting to a database on a remote server (as opposed to connecting to a local Access database).
I wouldn't recommend doing this, personally.
to upsize or not to upsize - that is the question...(or was for us)
kind of a big deal to step up to sqlserver....we kind of dodged it by going to a WAN replication service from AccessTables.com and stayed with Access....at least for the time being.....the upsizing was just one issue...dealing with a web front end or terminal services was part of it too...