Top 60 Oracle Blogs

Recent comments

Oakies Blog Aggregator

What is Object Storage?

By Franck Pachot

. 600w" sizes="(max-width: 300px) 100vw, 300px" />
I’ve always been working with databases. Before the cloud era, the most abstract term was “data”. A variable in memory is data. A file is data. A block of disk contains data. We often created a ‘/data’ directory to put everything that is not binaries and configuration files. I’ll always remember when I did that while working in Dakar. My colleagues were laughing for minutes – my Senegalese followers will understand why. “Data”, like “information” is abstract (which is a reason why it is not plural). It makes sense only when you associate it with a container: data bank, database, datafile, datastore… In database infrastructure, we store data in files or block storage where we read and write by pages: read one or many continuous blocks, bring them in memory, update them in memory, write those blocks back. And to export and import data outside of the database, we store them in files, within filesystem that can be local or remote (like NFS). But it is basically the same: you open a file, you seek to the right offset, you read or write, you synchronize, you keep the file opened until you don’t need to work on it anymore, and then you close it. This API is so convenient, that finally in Linux everything is a file: you write to the network with file descriptors, you access the block devices with /dev ones, you output to the screen with stderr and stdout,…

And then came the cloud which maps most of the artifacts we have in the data center: virtual network, virtual machines, block storage, network file systems,… but then came a new invention: the Object Storage. What is an object? Well.. it is data… Then, what is new? It has some metadata associated with it… But that’s what a filesystem provides then? Well.. here we have no hierarchy, no directories, but more metadata, like tags. What? Everything in the cloud without folders and directories? No, we have buckets… But without hierarchy, how do you avoid name collision? No problem, each object has a UUID identifier.

My hope is that you find this blog post when you “google” to know what is object storage. It is quite common that “experts” answer a quick “did you google for it?” in forums without realizing that actually, what makes you an expert is not what you know but how accurate you can be when “googling” for it.

If you already know what is an Object Storage, you will probably find more information on each cloud provider documentation. But what if you don’t know at all. I’m writing this blog post because a friend without cloud knowledge was trying to understand what is Object Storage.

He is an Oracle DBA and came to this page about Oracle Cloud Object Storage:

Overview of Object Storage
Oracle Cloud Infrastructure offers two distinct storage class tiers to address the need for both performant, frequently accessed “hot” storage, and less frequently accessed “cold” storage. Storage tiers help you maximize performance where appropriate and minimize costs where possible.
Use Object Storage for data to which you need fast, immediate, and frequent access. Data accessibility and performance justifies a higher price to store data in the Object Storage tier.

And you know what a DBA thinks where he reads “performant, frequently accessed hot storage”, and “fast, immediate, and frequent access”? This is for a database. In the whole page, there are some use case described. But no mention of “read” and “write”. No mention of “random” or “sequential” access. Nothing that explicitly tells you that the Object Store is not where you want to put your database datafiles. It mentions some use-cases that seem very related with databases (Big Data Support, Backup, Repository, Large Datasets,…) and it mentions features that are very related to databases (consistency, durability, metadata, encryption).

Basically, if you already know what it is, you have a nice description. But if you are new to the cloud and try to match this service with something you know, then you are completely misled. Especially if you didn’t read about Block Storage before.

Are all cloud providers doing the same mistake? Here is AWS definition:
Cloud object storage makes it possible to store practically limitless amounts of data in its native format

The Amazon Simple Storage Service (Amazon S3) has also no mention of read/write workloads and random/sequential access. The features are Durability, Availability, & Scalability. Nothing is telling you that it is not designed for database files.

Google Cloud may be more clear:
Object storage for companies of all sizes. Store any amount of data. Retrieve it as often as you’d like. Good for “hot” data that’s accessed frequently, including websites, streaming videos, and mobile apps.
The “Store” and “Retreive as often” gives the idea of write once and read many, as a whole. This is not for databases. But again “accessed frequently” should mention “read” workload.

Microsoft is known to listen and talk to their users. Look at Azure name and definition for this:
Blob storage: Massively scalable and secure object storage for cloud-native workloads, archives, data lakes, high-performance computing, and machine learning

Yes, that rings a bell or two for a database person. BLOB is exactly what we use in databases to store what a cloud practitioner stores in an Object Storage. Here is the “O” for “Object”, the same as in “Binary Large Object”. You do not store database files in an Object Storage. Databases need block volumes and you have block storage services. You don’t store a hierarchy of folders and files in an Object Storage. File servers need protocols providing shared access and a structure of filesystem trees. You store everything else in an Object Storage. Think of it like writing to tape but reading like if the tape was transformed to SSD. In this store you put files and can get them efficiently. I’m talking about “store”, “put” and “get” like in a document database. But documents can be terabytes. And you can read those files with a database, as if it were a BLOB, like Oracle Autonomous Datawarehouse reading ORC, Parquet, or Avro. Or Amazon Athena running SQL queries on S3 files.

I hope what is an Object Storage is more clear for you, especially if you are in databases. And also remember that what is easy to google for you may be impossible to find for someone else. You need concepts and Cloud Practitioner certifications are really good for that.

Cet article What is Object Storage? est apparu en premier sur Blog dbi services.

Oracle 19c Automatic Indexing: CBO Incorrectly Using Auto Indexes Part I (Neighborhood Threat)

Following on from my previous few posts on “data skew”, I’m now going to look at it from a slightly different perspective, where there is an inherent relationship between columns. The CBO has difficulties in recognising (by default) that some combinations of column values are far more common than other combinations, resulting in incorrect cardinality […]

Amazon DynamoDB: a r(el)ational Glossary

By Franck Pachot

There are many NoSQL databases. And, because SQL is an ISO standard, “No SQL” also means “No Standard”. Many have a similar API and similar objects, but with completely different names. Today, NoSQL databases are used as an additional datastore for some well-defined use cases for which a hashed key-value store fits better than a relational table. And it quickly became “Not Only SQL” as it is complementary to RDBMS databases using SQL. But at the origin, the idea was to replace the RDBMS databases, refusing the SQL API, and then inventing a “No SQL” data store. When you want to replace something rather than proposing something new, you often adopt the same language to make it look similar. And this why, in my opinion we find some relational database terms like “Table” and “Index”. But they have a different meaning. Here is a dictionary where I try to explain the DynamoDB artifacts and differentiate from their Relational and SQL meaning.


This is taken from the Relational semantic. An “Attribute” (a “Column” in SQL) is an element of a “Relation” (a “Table” in SQL) for which a “Tuple” (a “Row” in SQL) can have a value. Basically, when you store a list of your friends, they have a first name, a last name, a birthdate,… and many other properties. “First Name”, “Last Name” are attributes of the relation “Friend”. The combination of those properties is a fact like a sentence saying “I have a friend whose first name is Donald and last name is Chamberlain and was born on December 21, 1944”. In DynamoDB an attribute is a JSON member. The previous tuple could be written as: {“first name”:”Donald”, “last name”: “Chamberlain”, birthdate: “1944-12-21”}.

But there are many differences. A relational attribute has a “Domain” (a “Data Type” in SQL) which defines the set of possible values. A “First Name” or “Last Name” is a combination of characters within a characterset, with a specific maximum length (because the application that manipulates it have some memory buffers, screen width, paper length,… physical limits). A “Birthdate” is a day within a specific calendar,… They are constrained so that the developer that reads an attribute knows that she will not encounter any edge case at runtime. If the domain says that the first name holds maximum 30 of [A-Za-z-‘] characters, then she knows that she will not buffer overflow when she allocates 30 bytes (or 60 in UTF-16, or 120 in UTF-8), and that she doesn’t have to code some additional assertions in her code to be sure there’s no non-alphanumeric characters there. In JSON you can encounter any character string in a value. And DynamoDB attributes have only a few data type constraints: Null, Number, String, Boolean, Binary. And they are defined per attribute value as there is no schema. The format of a date is just a character string with a convention. Nothing will tell you that “1752-09-13” is not a valid date.

If you come from Oracle, you can see a DynamoDB attribute like the ANYDATA data type:

DEMO@atp> create table demo (att anydata);
Table DEMO created.
DEMO@atp> insert into demo values (anydata.convertNumber(42));
1 row inserted.
DEMO@atp> insert into demo values (anydata.convertVarchar2(q'{Don't panic}'));
1 row inserted.
DEMO@atp> select * from demo;

Another difference is that a relational attribute should be scalar (holds only one value). DynamoDB can store a whole hierarchy in a JSON attribute. The 1st Normal Form says that the value must be atomic even if Chris Date accepts nested tables in 1NF. And SQL allows this. Actually, it is not NoSQL vs. SQL here. Usually, in SQL you store hierarchies into another table but can store it as a hierarchy with nested tables, XML, or JSON. Usually, in NoSQL document database you store a whole hierarchy as one value but the “single-table” design splits them into multiple items of a collection.

If you compare with MongoDB, a DynamoDB attribute is similar to a MongoDB field.


Even if an Item in DynamoDB looks like a relational “Tuple” (or “Row” in SQL) there’s no ambiguity. We are in a key-value store and the item is the value. We are in a key-value store and the item is the value. This would be stored in a SQL BLOB (Binary Large Object) in a relational database. As JSON, it could be the OSON datatype in Oracle or JSONB in PostgreSQL. It is a column, not a row.

The equivalent of a DynamoDB item would be a BLOB storing JSON in a table with a key and this BLOB only. This is, for example, how SODA, the NoSQL API for Oracle RDBMS, stores a collection:

DEMO@atp1_tp> soda create MyDocumentStore
Successfully created collection: MyDocumentStore

DEMO@atp1_tp> ddl "MyDocumentStore"

  CREATE TABLE "DEMO"."MyDocumentStore"
         CHECK ("JSON_DOCUMENT" is json format oson (size limit 32m)) ENABLE,
         PRIMARY KEY ("ID") 
   ) ;

Here JSON_DOCUMENT is in format OSON, the Oracle binary implementation for JSON, stored in a BLOB which can be any size. The “soda” and “ddl” are standard SQLcl commands.

If you compare with MongoDB, a DynamoDB item is similar to a MongoDB document except that it is a JSON string value where MongoDB can store larger documents (up to 16MB) in binary format (BSON). But we will see that the idea is to split a document to multiple items in DynamoDB, with a key starting with the same prefix to be hashed and range partitioned together.


This is a NoSQL term. A “Collection” is a set of “Item”. But in DynamoDB this has a specific meaning and the SQL equivalent would be a table “Partition”. When you HASH partition an RDBMS table, you do the same as a DynamoDB collection: you apply a hash function on the partition key value which determines the physical segment of the table where you want to store it. This is how you scale any database, NoSQL or RDBMS: partition by hash and distribute those partition over the storage, processes, and maybe nodes.

A DynamoDB collection is not the same as a MongoDB collection. It is more like a chunk. What is called a collection in MongoDB is called a table in DynamoDB.


This is where using the same name in DynamoDB as in SQL database can mislead to a bad data model. A “Relation” (“Table” in SQL) is a set of tuples (“rows”) that belongs to the same business entity. In DynamoDB you can store anything in the same table as it is just a key-value store. For example, you store the customer information with their orders within the same table and within the same collection. And that’s the goal: the data model is optimized for one use-case and if this use case is to display one customer orders, then you want to retrieve all that with one ‘get’. A SQL table has the opposite goal: centralize the data for many use-cases. You have one table with your customers. And one table with your orders. And the CRM can query the customers only. The Delivery will query only the orders. The Marketing wants to get some customer information for specific orders. The billing wants to get all orders for a customer…

Again, it is not NoSQL vs. SQL and you can have some nuances of both. In a RDBMS when you want to pre-build a hierarchy to optimize a specific use-case, you get the RDBMS to maintain transparently a redundant physical store like an index or a materialized view. And in DynamoDB the “single-table” design splits a document into multiple items to get it accessed from multiple use cases.

Actually, a Table in DynamoDB could be seen as a Materialized View in SQL rather than as a table. It is pre-built by the application and not by the RDBMS but it is like a view (purpose-built for specific queries) and materialized (the physical colocation of data is there by design). The worst mistake a developer can do is consider it as a SQL table and store related items in multiple DynamoDB tables. This would be bad for performance and cost. What you store in a DynamoDB table is probably at the same scope as what you store in a SQL schema for a small application.


An index in RDBMS is a physical structure that provides fast access to a small number of rows because it is ordered on a value. That’s the same idea in DynamoDB: access with another attribute than the key. Another similarity is the fact that the index is transparently maintained. The developer declares the index and doesn’t have to take care of the maintenance in his code. Of course, in NoSQL the maintenance of the index can be in eventual consistency but it is still automatically maintained. However, there is a huge difference for your coding effort. In RDBMS you never query the index. The developer doesn’t have to know the physical design. An index is a physical structure created for performance reasons. SQL provides a logical view on the database: you query the table and the RDBMS optimizer decides how it is the most efficient get the rows required for the result. In DynamoDB you see the indexes as a table: you need to “get” on them if you want to use them.

In NoSQL, you have no optimizer. You do it in the code. If you add a new index for fast access, you need to change the code to use it. In RDBMS you have the agility to add an index (even online without application interruption in some RDBMS) and queries will use it when it is appropriate. It is all about having a simple API with calls to embed in your procedural code or calling a database service that does the procedural access for you.

In DynamoDB you have local indexes and global indexes. That’s the same idea as in RDBMS where in index can be local, partitioned in the same way as the table, or global, partitioned on another value. And you find the same optimization ideas. I have a few blog posts related to covering indexes in DynamoDB.

Primary Key

In DynamoDB as well as in SQL a Primary Key is a unique identifier for an item or row. It is enforced to be unique: If you put an item that already exists, it will replace it (the default in DynamoDB and can do the same in SQL with the MERGE statement) or reject it (the default in SQL and you can do the same in DynamoDB with an attribute_not_exists condition). RDBMS usually uses the primary key for the physical organization as well. Oracle is very agile on that and only specific table organization (like IOT) requires that the physical order follows the primary key. Other RDBMS (like MySQL InnoDB) will store the tables clustered on the primary key. In DynamoDB, like in any key-value store, the primary key determines the physical access through physical structures. A DynamoDB is hash partitioned on the first column of the primary key. And may be sorted on a second attribute. If you want to hash on multiple attributes, your code will concatenate the values to be the first attribute. Again, NoSQL provides a simple API and the developer does the additional logic in the procedural code. In RDBMS, a primary key is a declared constraint that may, or may not, be related to the physical organization. And can be compound with multiple columns. RDBMS can also have additional keys for which the uniqueness is enforced and for which the referential integrity can be validated.

In summary

This glossary is aimed at people working in SQL and NoSQL to avoid confusion between the different meanings of the same terms used in RDBMS and DynamoDB. The most important you should remember is that a Table in DynamoDB is different than a Table in SQL. Yon don’t need to separate to different tables because of the size: tables are automatically partitioned. You don’t need to separate to different tables because of the structure: all are key-value. And, you will quickly have a generic key name where you put different entities and the key value being build to control the clustering of data. Think of a DynamoDB table as a key-value store. You can have multiple stores to isolate multiple applications with different performance requirement (and cost). But an application should store its data into one store only. I’m not giving examples here because you can follow the two links on “single-table” which will bring you to the excellent examples from Rick Houlian and Alex DeBrie. I wrote this blog post as an expansion of my following tweet:

Cet article Amazon DynamoDB: a r(el)ational Glossary est apparu en premier sur Blog dbi services.

Oracle 19c Automatic Indexing: Data Skew Part III (The Good Son)

  I’m going to expand just a tad on my previous posts on data skew and run a simple query that returns a few rows based on a column predicate AND another query on the same column that returns many rows. The following table has a CODE column as with previous posts with the data […]

Video : Instance Caging to Manage CPU Usage

In today’s video we’ll discuss instance caging to manage CPU usage. This can be useful when we are trying to consolidate multiple instances on a single server.

This video is based on the following article.

The star of today’s video is the beard belonging to Victor Torres. I feel totally inadequate with my patchy stubble… </p />

    	  	<div class=

Oracle 19c Automatic Indexing: Data Skew Part II (Everything’s Alright)

In my previous post, I discussed an example with data skew, in which the Automatic Indexing process created a new index, but somehow the CBO when using the index estimated the correct cardinality estimate even though no histograms were explicitly calculated. In this post I’ll answer HOW this achieved by the CBO. Get some idea […]

When can I use SQL Macros?

One of the very cool features we’ve been talking about for 20c is SQL Macros. But you no longer need to wait for a future release of the database to get access to all the goodness of SQL Macros.

Why? Because much of the functionality has now been backported to 19c, and is also now officially in the documentation so there’s no ambiguity as to whether you are supported to use them or not. They’ll be coming soon to an RU near you </p />

    	  	<div class=

Age calculations – Just how old ARE you?

Any database application that stores information about people will very likely store a person’s date of birth as part of that data. Whether it be for marketing purposes, or part of the security checks for a password reset, or part of the authentication when the inevitable call centre calls you with their “latest, greatest offer”, the date of birth is common.

But when it comes to reporting, typically it is not the date of birth that we present on our screen or hard-copy, but the person’s age. Clearly we cannot store a persons age in the database because it changes every day, month or year depending on the granularity with which you present it. Which leads to the ponderance – Surely it cannot be that hard to calculate someone’s age from their date of birth?

As it turns out, it is not as simple as it looks, and often developers have come up with “close but not close” enough methods to calculate the age, and by “not close enough” I mean, the methods break down as we hit boundary cases.

Lets create some test data, where the columns in the table T below are

  • birth – the date of birth someone provides to our application
  • sys_date – a representation of the standard “sysdate” function which reflects the date at which we run our age calculation
  • true_age – what the correct age is given the “birth” and “sys_date” column values.

SQL> create table t
  2    ( birth      date,
  3      sys_date   date,
  4      true_age   int );

Table created.

SQL> insert into t values ( date '2000-05-12',date '2016-03-30',15 );

1 row created.

SQL> insert into t values ( date '2000-05-12',date '2016-05-30',16 );

1 row created.

SQL> insert into t values ( date '2000-05-12',date '2016-05-12',16 );

1 row created.

SQL> insert into t values ( date '2000-05-12',date '2076-06-12',76 );

1 row created.

SQL> insert into t values ( date '2000-02-29',date '2013-03-01',13 );

1 row created.

SQL> insert into t values ( date '2000-02-29',date '2016-02-29',16 );

1 row created.

SQL> insert into t values ( date '2000-02-29',date '2017-02-28',16 );

1 row created.

SQL> insert into t values ( date '2000-02-29',date '2087-02-28',86 );

1 row created.

SQL> insert into t values ( date '2000-01-01',date '2087-12-31',87 );

1 row created.

Using this data, lets look at common yet flawed mechanism for calculating age. This first one I’ve seen many times over the course of my career, namely to do a simple date subtraction. Sometimes people divide by 365, or 366 or even 365.25, but no matter what divisor is chosen, you’ll always hit some errors in the calculation.

SQL> select
  2  x.*,
  3   case when true_age = calculated_age then 'OK' else 'ERROR' end tag
  4  from
  5  (
  6  select
  7    t.*,
  8    trunc((sys_date-birth)/365) calculated_age
  9  from t
 10  ) x;

--------- --------- ---------- -------------- -----
12-MAY-00 30-MAR-16         15             15 OK
12-MAY-00 30-MAY-16         16             16 OK
12-MAY-00 12-MAY-16         16             16 OK
12-MAY-00 12-JUN-76         76             76 OK
29-FEB-00 01-MAR-13         13             13 OK
29-FEB-00 29-FEB-16         16             16 OK
29-FEB-00 28-FEB-17         16             17 ERROR
29-FEB-00 28-FEB-87         86             87 ERROR
01-JAN-00 31-DEC-87         87             88 ERROR

9 rows selected.

Side note: Date subtraction in itself needs care. See my recent post for more details on this.

A better method is to take advantage of the MONTHS_BETWEEN function in the Oracle Database, because unlike the days in a year which is variable, there is always 12 months in a year, so this sounds more promising as a divisor. However, as you can see below, even MONTHS_BETWEEN struggles when someone has a date of birth on a “leap day”. How annoying of them Smile

SQL> select
  2  x.*,
  3   case when true_age = calculated_age then 'OK' else 'ERROR' end tag
  4  from
  5  (
  6  select
  7    t.*,
  8    trunc(months_between(sys_date,birth)/12) calculated_age
  9  from t
 10  ) x;

--------- --------- ---------- -------------- -----
12-MAY-00 30-MAR-16         15             15 OK
12-MAY-00 30-MAY-16         16             16 OK
12-MAY-00 12-MAY-16         16             16 OK
12-MAY-00 12-JUN-76         76             76 OK
29-FEB-00 01-MAR-13         13             13 OK
29-FEB-00 29-FEB-16         16             16 OK
29-FEB-00 28-FEB-17         16             17 ERROR
29-FEB-00 28-FEB-87         86             87 ERROR
01-JAN-00 31-DEC-87         87             87 OK

9 rows selected.

Somewhat counter-intuitively, a reliable formula to derive a persons age is to dispense with the date arithmetic altogether and convert the dates to numbers.

SQL> select
  2  x.*,
  3   case when true_age = calculated_age then 'OK' else 'ERROR' end tag
  4  from
  5  (
  6  select
  7    t.*,
  8    trunc((to_number(to_char(sys_date,'YYYYMMDD'))-
  9          to_number(to_char(birth,'YYYYMMDD')))/10000) calculated_age
 10  from t
 11  ) x;

--------- --------- ---------- -------------- -----
12-MAY-00 30-MAR-16         15             15 OK
12-MAY-00 30-MAY-16         16             16 OK
12-MAY-00 12-MAY-16         16             16 OK
12-MAY-00 12-JUN-76         76             76 OK
29-FEB-00 01-MAR-13         13             13 OK
29-FEB-00 29-FEB-16         16             16 OK
29-FEB-00 28-FEB-17         16             16 OK
29-FEB-00 28-FEB-87         86             86 OK
01-JAN-00 31-DEC-87         87             87 OK

9 rows selected.

You can see how this neat little trick works by looking at the components of the expression

SQL> select
  2    to_number(to_char(sys_date,'YYYYMMDD')) d1,
  3    to_number(to_char(birth,'YYYYMMDD')) d2,
  4    to_number(to_char(sys_date,'YYYYMMDD')) -
  5      to_number(to_char(birth,'YYYYMMDD')) delt
  6  from t;

        D1         D2       DELT
---------- ---------- ----------
  20160330   20000512     159818
  20160530   20000512     160018
  20160512   20000512     160000
  20760612   20000512     760100
  20130301   20000229     130072
  20160229   20000229     160000
  20170228   20000229     169999
  20870228   20000229     869999
  20871231   20000101     871130

9 rows selected.

The conversion to numbers means that elements like Feb 28th and Feb 29th are still distinct as opposed to both being seen as “the last day of Feburary” by internal date functions, and (for example on the second last line), the age calculation stay just below 87 as opposed to crossing over the boundary to 87.

Now that you have a reliable formula, you can easily add the AGE as a column in a view on your table and not have to worry about the internals.

Start Taking Donations, Tips, and Contributions for Your Creative and Professional Pursuits

With our growing suite of payment features, we want to make it easier for you to earn money on With the Donations block, you can now accept credit and debit card payments for all types of donations, earning revenue and growing your base of supporters. Collect donations, tips, and contributions on your website to fuel your creative and professional projects or to support and grow your business or organization.

Donations block example for an arts organization 2048w, 150w, 300w, 768w" sizes="(max-width: 1024px) 100vw, 1024px" />

What can you accept donations for?

You can collect financial contributions on your website for just about anything — the sky really is the limit. Here are examples of things people support through donations:

  • Creative pursuits for musicians, artists, designers, writers, and more
  • Concrete creations like podcasts, video games, music clips, and photography
  • Bloggers and content creators of all shapes and sizes
  • Everyday passions like news summaries and mindfulness exercises
  • Professional endeavors including civic engagement and professional development
  • Nonprofits and community, religious, and political organizations

Donations block examples for a musician and radio station 91w, 182w, 768w, 932w" sizes="(max-width: 621px) 100vw, 621px" /> 150w, 300w, 768w, 1132w" sizes="(max-width: 1024px) 100vw, 1024px" />

Continue to build your community by engaging with your supporters in a unique and authentic way. People can opt to support you through one-time, monthly, or yearly contributions, and the Donations block lets you engage with each level for a more custom experience. For example, you might send your monthly supporters additional content and information on top of what you send your one-time supporters.

As you ask for support, we’ll handle the rest — the credit and debit card payment processing, sending receipts, reporting, and more.

Ask for your first donation

Above all, the first step in earning money on your website is to ask for it. You can add a Donations block to your website in a matter of minutes; watch this short video to learn how. Alternatively, a step-by-step guide follows below.

How to use Donations block to earn money on your website

  • To use the Donations block, you’ll need a website with any paid plan — Personal, Premium, Business, or eCommerce.
  • On any page or post, add the Donations block.
  • To set up your first donation request, create a Stripe account if you don’t have one already. Stripe is the company we’ve partnered with to process credit and debit card payments in a safe, secure, and speedy way.
  • After you’ve connected to Stripe, configure the block’s settings, like how often you’re asking for donations. It can be any combination of single (one-time), monthly recurring, or yearly recurring donations.
  • Set three donation amounts that you’d like visitors to choose from for any of the payment intervals. These are fully customizable. Be sure to set your currency as well.
  • You can also allow visitors to donate what they want — essentially a blank box for them to fill out how much money they would like to give.
  • Review all of the text in your Donations block — you can edit every single letter, so be sure to provide enough information for your visitors about their donation, why you’re asking for it, etc.
  • Publish your block!
  • You can manage your supporters, see earnings, and keep an eye on other metrics in the Earn dashboard.
  • Last but not least, tell others about what you’re doing! Share on social media, email, and however you best communicate with people who might donate to your cause.

A suite of payment features to fit your needs

Looking to accept payments for something else? There are several other payment features on to suit your needs and help you make money with your website. In addition to the new Donations block, here are other features:

  • Payments block: Accept one-time or recurring payments on your website for physical items, digital downloads, services, memberships, subscriptions, and more.
  • Premium Content block: Create one-time, monthly, or yearly subscription options to share select content with those who pay for it — text, images, videos, or any kind of content. Exclusive content can be sent to email inboxes or viewed on your website.
  • Paid newsletters: Using the Premium Content block, you can share your site’s latest premium content via email newsletters in a fully automated way.
  • eCommerce Store: Turn your website into an eCommerce store and sell products and services seamlessly.

If you’re interested in setting up a membership- or subscription-based website, learn more about getting started with memberships and subscriptions.

Add the Donations block and start earning money with your website today!

Oracle 19c Automatic Indexing: Data Skew Part I (A Saucerful of Secrets)

When it comes to Automatic Indexes, things can become particularly interesting when dealing with data skew (meaning that some columns values are much less common than other column values). The next series of blog posts will look at a number of different scenarios in relation to how Automatic Indexing works with data that is skewed […]